ਅੱਜ, ਜ਼ਿਆਦਾਤਰ ਸੌਫਟਵੇਅਰ ਉਤਪਾਦ ਟੀਮਾਂ ਵਿੱਚ ਵਿਕਸਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਸਫਲ ਟੀਮ ਦੇ ਵਿਕਾਸ ਲਈ ਹਾਲਤਾਂ ਨੂੰ ਇੱਕ ਸਧਾਰਨ ਚਿੱਤਰ ਦੇ ਰੂਪ ਵਿੱਚ ਦਰਸਾਇਆ ਜਾ ਸਕਦਾ ਹੈ.

ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਆਪਣਾ ਕੋਡ ਲਿਖ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:

1. ਰਾਬੋਟਾਏਟ.
2. ਇਹ ਤੁਹਾਡੇ ਸਹਿਕਰਮੀਆਂ ਦੁਆਰਾ ਲਿਖੇ ਕੋਡ ਸਮੇਤ, ਕੁਝ ਵੀ ਨਹੀਂ ਤੋੜਦਾ ਹੈ।

ਜੇਕਰ ਦੋਵੇਂ ਸ਼ਰਤਾਂ ਪੂਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਸਫਲਤਾ ਦੇ ਰਾਹ 'ਤੇ ਹੋ। ਇਹਨਾਂ ਸਥਿਤੀਆਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਜਾਂਚਣ ਅਤੇ ਲਾਭਕਾਰੀ ਮਾਰਗ ਤੋਂ ਭਟਕਣ ਲਈ, ਅਸੀਂ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਦੇ ਨਾਲ ਆਏ ਹਾਂ।

CI ਇੱਕ ਵਰਕਫਲੋ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਆਪਣੇ ਕੋਡ ਨੂੰ ਸਮੁੱਚੇ ਉਤਪਾਦ ਕੋਡ ਵਿੱਚ ਜਿੰਨੀ ਵਾਰ ਸੰਭਵ ਹੋ ਸਕੇ ਜੋੜਦੇ ਹੋ। ਅਤੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਏਕੀਕ੍ਰਿਤ ਹੀ ਨਹੀਂ ਹੁੰਦੇ, ਪਰ ਇਹ ਵੀ ਲਗਾਤਾਰ ਜਾਂਚ ਕਰਦੇ ਹੋ ਕਿ ਸਭ ਕੁਝ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਕਿਉਂਕਿ ਤੁਹਾਨੂੰ ਬਹੁਤ ਅਤੇ ਅਕਸਰ ਜਾਂਚ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ, ਇਹ ਆਟੋਮੇਸ਼ਨ ਬਾਰੇ ਸੋਚਣ ਯੋਗ ਹੈ। ਤੁਸੀਂ ਹੱਥੀਂ ਹਰ ਚੀਜ਼ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਤੁਹਾਨੂੰ ਅਜਿਹਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ, ਅਤੇ ਇਸਦਾ ਕਾਰਨ ਇੱਥੇ ਹੈ।

• ਪਿਆਰੇ ਲੋਕ. ਕਿਸੇ ਵੀ ਪ੍ਰੋਗਰਾਮਰ ਦਾ ਇੱਕ ਘੰਟੇ ਦਾ ਕੰਮ ਕਿਸੇ ਵੀ ਸਰਵਰ ਦੇ ਕੰਮ ਦੇ ਇੱਕ ਘੰਟੇ ਨਾਲੋਂ ਮਹਿੰਗਾ ਹੁੰਦਾ ਹੈ।
• ਲੋਕ ਗਲਤੀਆਂ ਕਰਦੇ ਹਨ. ਇਸ ਲਈ, ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਪੈਦਾ ਹੋ ਸਕਦੀਆਂ ਹਨ ਜਦੋਂ ਟੈਸਟ ਗਲਤ ਬ੍ਰਾਂਚ 'ਤੇ ਚਲਾਏ ਗਏ ਸਨ ਜਾਂ ਟੈਸਟਰਾਂ ਲਈ ਗਲਤ ਕਮਿਟ ਕੰਪਾਇਲ ਕੀਤੇ ਗਏ ਸਨ।
• ਲੋਕ ਆਲਸੀ ਹਨ. ਸਮੇਂ-ਸਮੇਂ 'ਤੇ, ਜਦੋਂ ਮੈਂ ਕੋਈ ਕੰਮ ਪੂਰਾ ਕਰਦਾ ਹਾਂ, ਤਾਂ ਇਹ ਵਿਚਾਰ ਪੈਦਾ ਹੁੰਦਾ ਹੈ: "ਇੱਥੇ ਜਾਂਚ ਕਰਨ ਲਈ ਕੀ ਹੈ? ਮੈਂ ਦੋ ਲਾਈਨਾਂ ਲਿਖੀਆਂ - ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ! ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਵਿੱਚੋਂ ਵੀ ਕਈ ਵਾਰ ਅਜਿਹੇ ਵਿਚਾਰ ਆਉਂਦੇ ਹਨ। ਪਰ ਤੁਹਾਨੂੰ ਹਮੇਸ਼ਾ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਅਵਿਟੋ ਮੋਬਾਈਲ ਡਿਵੈਲਪਮੈਂਟ ਟੀਮ ਵਿੱਚ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਅਤੇ ਵਿਕਸਤ ਕੀਤਾ ਗਿਆ, ਕਿਵੇਂ ਉਹ ਪ੍ਰਤੀ ਦਿਨ 0 ਤੋਂ 450 ਬਿਲਡ ਤੱਕ ਗਏ, ਅਤੇ ਇਹ ਬਿਲਡ ਮਸ਼ੀਨਾਂ ਦਿਨ ਵਿੱਚ 200 ਘੰਟੇ ਇਕੱਠੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਨਿਕੋਲਾਈ ਨੇਸਟਰੋਵ (nnesterov) CI/CD ਐਂਡਰੌਇਡ ਐਪਲੀਕੇਸ਼ਨ ਦੀਆਂ ਸਾਰੀਆਂ ਵਿਕਾਸਵਾਦੀ ਤਬਦੀਲੀਆਂ ਵਿੱਚ ਇੱਕ ਭਾਗੀਦਾਰ ਹੈ।

ਕਹਾਣੀ ਇੱਕ ਐਂਡਰੌਇਡ ਕਮਾਂਡ ਦੀ ਉਦਾਹਰਣ 'ਤੇ ਅਧਾਰਤ ਹੈ, ਪਰ ਜ਼ਿਆਦਾਤਰ ਪਹੁੰਚ iOS 'ਤੇ ਵੀ ਲਾਗੂ ਹਨ।

ਇੱਕ ਵਾਰ, ਇੱਕ ਵਿਅਕਤੀ ਅਵੀਟੋ ਐਂਡਰੌਇਡ ਟੀਮ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਸੀ। ਪਰਿਭਾਸ਼ਾ ਅਨੁਸਾਰ, ਉਸਨੂੰ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਤੋਂ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ: ਏਕੀਕ੍ਰਿਤ ਕਰਨ ਵਾਲਾ ਕੋਈ ਨਹੀਂ ਸੀ।

ਪਰ ਐਪਲੀਕੇਸ਼ਨ ਵਧਦੀ ਗਈ, ਵੱਧ ਤੋਂ ਵੱਧ ਨਵੇਂ ਕੰਮ ਦਿਖਾਈ ਦਿੱਤੇ, ਅਤੇ ਟੀਮ ਉਸ ਅਨੁਸਾਰ ਵਧੀ. ਕਿਸੇ ਸਮੇਂ, ਇਹ ਕੋਡ ਏਕੀਕਰਣ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਵਧੇਰੇ ਰਸਮੀ ਤੌਰ 'ਤੇ ਸਥਾਪਤ ਕਰਨ ਦਾ ਸਮਾਂ ਹੈ। ਗਿੱਟ ਪ੍ਰਵਾਹ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਗਿਆ ਸੀ।

ਗਿੱਟ ਵਹਾਅ ਦੀ ਧਾਰਨਾ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣੀ ਜਾਂਦੀ ਹੈ: ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਦੀ ਇੱਕ ਆਮ ਵਿਕਾਸ ਸ਼ਾਖਾ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਹਰੇਕ ਨਵੀਂ ਵਿਸ਼ੇਸ਼ਤਾ ਲਈ, ਡਿਵੈਲਪਰ ਇੱਕ ਵੱਖਰੀ ਸ਼ਾਖਾ ਨੂੰ ਕੱਟਦੇ ਹਨ, ਇਸ ਲਈ ਵਚਨਬੱਧ ਹੁੰਦੇ ਹਨ, ਧੱਕਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਉਹ ਆਪਣੇ ਕੋਡ ਨੂੰ ਵਿਕਾਸ ਸ਼ਾਖਾ ਵਿੱਚ ਮਿਲਾਉਣਾ ਚਾਹੁੰਦੇ ਹਨ, ਤਾਂ ਇੱਕ ਖੋਲ੍ਹੋ ਬੇਨਤੀ ਖਿੱਚੋ. ਗਿਆਨ ਨੂੰ ਸਾਂਝਾ ਕਰਨ ਅਤੇ ਪਹੁੰਚਾਂ 'ਤੇ ਚਰਚਾ ਕਰਨ ਲਈ, ਅਸੀਂ ਕੋਡ ਸਮੀਖਿਆ ਪੇਸ਼ ਕੀਤੀ, ਅਰਥਾਤ, ਸਹਿਕਰਮੀਆਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਦੇ ਕੋਡ ਦੀ ਜਾਂਚ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਜਾਂਚ ਕਰਦਾ ਹੈ

ਆਪਣੀਆਂ ਅੱਖਾਂ ਨਾਲ ਕੋਡ ਦੇਖਣਾ ਠੰਡਾ ਹੈ, ਪਰ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਇਸ ਲਈ, ਆਟੋਮੈਟਿਕ ਜਾਂਚ ਸ਼ੁਰੂ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ।

• ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ARK ਅਸੈਂਬਲੀ.
• ਬਹੁਤ ਸਾਰਾ ਜੂਨਿਟ ਟੈਸਟ.
• ਅਸੀਂ ਕੋਡ ਕਵਰੇਜ 'ਤੇ ਵਿਚਾਰ ਕਰਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਅਸੀਂ ਟੈਸਟ ਚਲਾ ਰਹੇ ਹਾਂ।

ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਇਹ ਜਾਂਚਾਂ ਕਿਵੇਂ ਚਲਾਈਆਂ ਜਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਆਓ ਅਵੀਟੋ ਵਿੱਚ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਵੇਖੀਏ.

ਇਸ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਯੋਜਨਾਬੱਧ ਢੰਗ ਨਾਲ ਦਰਸਾਇਆ ਜਾ ਸਕਦਾ ਹੈ:

• ਇੱਕ ਡਿਵੈਲਪਰ ਆਪਣੇ ਲੈਪਟਾਪ 'ਤੇ ਕੋਡ ਲਿਖਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਥੇ ਏਕੀਕਰਣ ਜਾਂਚਾਂ ਚਲਾ ਸਕਦੇ ਹੋ - ਜਾਂ ਤਾਂ ਇੱਕ ਕਮਿਟ ਹੁੱਕ ਨਾਲ, ਜਾਂ ਬੈਕਗ੍ਰਾਉਂਡ ਵਿੱਚ ਚੈਕਾਂ ਨੂੰ ਚਲਾ ਸਕਦੇ ਹੋ।
• ਡਿਵੈਲਪਰ ਦੁਆਰਾ ਕੋਡ ਨੂੰ ਧੱਕਣ ਤੋਂ ਬਾਅਦ, ਉਹ ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ ਖੋਲ੍ਹਦਾ ਹੈ। ਇਸਦੇ ਕੋਡ ਨੂੰ ਵਿਕਾਸ ਸ਼ਾਖਾ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਲਈ, ਇੱਕ ਕੋਡ ਸਮੀਖਿਆ ਵਿੱਚੋਂ ਲੰਘਣਾ ਅਤੇ ਲੋੜੀਂਦੇ ਪੁਸ਼ਟੀਕਰਣਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। ਤੁਸੀਂ ਇੱਥੇ ਜਾਂਚਾਂ ਅਤੇ ਬਿਲਡਾਂ ਨੂੰ ਸਮਰੱਥ ਕਰ ਸਕਦੇ ਹੋ: ਜਦੋਂ ਤੱਕ ਸਾਰੇ ਬਿਲਡ ਸਫਲ ਨਹੀਂ ਹੁੰਦੇ, ਪੁੱਲ ਬੇਨਤੀ ਨੂੰ ਮਿਲਾਇਆ ਨਹੀਂ ਜਾ ਸਕਦਾ।
• ਪੁੱਲ ਬੇਨਤੀ ਨੂੰ ਮਿਲਾਉਣ ਤੋਂ ਬਾਅਦ ਅਤੇ ਕੋਡ ਨੂੰ ਵਿਕਾਸ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ, ਤੁਸੀਂ ਇੱਕ ਸੁਵਿਧਾਜਨਕ ਸਮਾਂ ਚੁਣ ਸਕਦੇ ਹੋ: ਉਦਾਹਰਨ ਲਈ, ਰਾਤ ​​ਨੂੰ, ਜਦੋਂ ਸਾਰੇ ਸਰਵਰ ਖਾਲੀ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਜਿੰਨੀਆਂ ਮਰਜ਼ੀ ਜਾਂਚਾਂ ਚਲਾਓ।

ਕਿਸੇ ਨੂੰ ਵੀ ਆਪਣੇ ਲੈਪਟਾਪ 'ਤੇ ਸਕੈਨ ਚਲਾਉਣਾ ਪਸੰਦ ਨਹੀਂ ਸੀ। ਜਦੋਂ ਇੱਕ ਡਿਵੈਲਪਰ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਪੂਰਾ ਕਰ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਇਸਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਧੱਕਣਾ ਚਾਹੁੰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ ਨੂੰ ਖੋਲ੍ਹਣਾ ਚਾਹੁੰਦਾ ਹੈ। ਜੇ ਇਸ ਸਮੇਂ ਕੁਝ ਲੰਬੀਆਂ ਜਾਂਚਾਂ ਸ਼ੁਰੂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਇਹ ਨਾ ਸਿਰਫ ਬਹੁਤ ਸੁਹਾਵਣਾ ਹੈ, ਬਲਕਿ ਵਿਕਾਸ ਨੂੰ ਵੀ ਹੌਲੀ ਕਰਦਾ ਹੈ: ਜਦੋਂ ਲੈਪਟਾਪ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਇਸ 'ਤੇ ਆਮ ਤੌਰ' ਤੇ ਕੰਮ ਕਰਨਾ ਅਸੰਭਵ ਹੈ.

ਸਾਨੂੰ ਸੱਚਮੁੱਚ ਰਾਤ ਨੂੰ ਚੈਕ ਚਲਾਉਣਾ ਪਸੰਦ ਸੀ, ਕਿਉਂਕਿ ਇੱਥੇ ਬਹੁਤ ਸਾਰਾ ਸਮਾਂ ਅਤੇ ਸਰਵਰ ਹੈ, ਤੁਸੀਂ ਘੁੰਮ ਸਕਦੇ ਹੋ। ਪਰ, ਬਦਕਿਸਮਤੀ ਨਾਲ, ਜਦੋਂ ਵਿਸ਼ੇਸ਼ਤਾ ਕੋਡ ਵਿਕਸਤ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਡਿਵੈਲਪਰ ਕੋਲ CI ਦੁਆਰਾ ਪਾਈਆਂ ਗਈਆਂ ਗਲਤੀਆਂ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਬਹੁਤ ਘੱਟ ਪ੍ਰੇਰਣਾ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਮੈਂ ਸਵੇਰ ਦੀ ਰਿਪੋਰਟ ਵਿਚ ਪਾਈਆਂ ਗਈਆਂ ਸਾਰੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਦੇਖਿਆ ਤਾਂ ਮੈਂ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਆਪਣੇ ਆਪ ਨੂੰ ਇਹ ਸੋਚਦਾ ਰਿਹਾ ਕਿ ਮੈਂ ਉਨ੍ਹਾਂ ਨੂੰ ਕਿਸੇ ਦਿਨ ਬਾਅਦ ਵਿਚ ਠੀਕ ਕਰ ਲਵਾਂਗਾ, ਕਿਉਂਕਿ ਹੁਣ ਜੀਰਾ ਵਿਚ ਇਕ ਵਧੀਆ ਨਵਾਂ ਕੰਮ ਹੈ ਜੋ ਮੈਂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ.

ਜੇਕਰ ਚੈਕ ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਤਾਂ ਕਾਫ਼ੀ ਪ੍ਰੇਰਣਾ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਜਦੋਂ ਤੱਕ ਬਿਲਡ ਹਰੇ ਨਹੀਂ ਹੁੰਦੇ, ਕੋਡ ਡਿਵੈਲਪ ਵਿੱਚ ਨਹੀਂ ਆਵੇਗਾ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੰਮ ਪੂਰਾ ਨਹੀਂ ਹੋਵੇਗਾ।

ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਨਿਮਨਲਿਖਤ ਰਣਨੀਤੀ ਚੁਣੀ: ਅਸੀਂ ਰਾਤ ਨੂੰ ਚੈਕਾਂ ਦਾ ਵੱਧ ਤੋਂ ਵੱਧ ਸੰਭਾਵਿਤ ਸੈੱਟ ਚਲਾਉਂਦੇ ਹਾਂ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਨਾਜ਼ੁਕ ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ 'ਤੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਲਾਂਚ ਕਰਦੇ ਹਾਂ। ਪਰ ਅਸੀਂ ਉੱਥੇ ਨਹੀਂ ਰੁਕਦੇ - ਸਮਾਨਾਂਤਰ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਜਾਂਚਾਂ ਦੀ ਗਤੀ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰਦੇ ਹਾਂ ਤਾਂ ਜੋ ਉਹਨਾਂ ਨੂੰ ਬੇਨਤੀ ਜਾਂਚਾਂ ਨੂੰ ਖਿੱਚਣ ਲਈ ਨਾਈਟ ਮੋਡ ਤੋਂ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਜਾ ਸਕੇ।

ਉਸ ਸਮੇਂ, ਸਾਡੀਆਂ ਸਾਰੀਆਂ ਬਿਲਡਾਂ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਪੂਰੀਆਂ ਹੋ ਗਈਆਂ ਸਨ, ਇਸਲਈ ਅਸੀਂ ਪੁੱਲ ਬੇਨਤੀ ਲਈ ਬਲੌਕਰ ਵਜੋਂ ARK ਬਿਲਡ, ਜੂਨਿਟ ਟੈਸਟ ਅਤੇ ਕੋਡ ਕਵਰੇਜ ਗਣਨਾਵਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕੀਤਾ। ਅਸੀਂ ਇਸਨੂੰ ਚਾਲੂ ਕੀਤਾ, ਇਸ ਬਾਰੇ ਸੋਚਿਆ, ਅਤੇ ਕੋਡ ਕਵਰੇਜ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਕਿਉਂਕਿ ਅਸੀਂ ਸੋਚਿਆ ਕਿ ਸਾਨੂੰ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

ਬੁਨਿਆਦੀ CI ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਥਾਪਤ ਕਰਨ ਵਿੱਚ ਸਾਨੂੰ ਦੋ ਦਿਨ ਲੱਗ ਗਏ (ਇਸ ਤੋਂ ਬਾਅਦ ਸਮੇਂ ਦਾ ਅਨੁਮਾਨ ਅਨੁਮਾਨਿਤ ਹੈ, ਸਕੇਲ ਲਈ ਲੋੜੀਂਦਾ ਹੈ)।

ਉਸ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਹੋਰ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕੀਤਾ - ਕੀ ਅਸੀਂ ਸਹੀ ਢੰਗ ਨਾਲ ਜਾਂਚ ਕਰ ਰਹੇ ਹਾਂ? ਕੀ ਅਸੀਂ ਪੁੱਲ ਬੇਨਤੀਆਂ 'ਤੇ ਬਿਲਡ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਚਲਾ ਰਹੇ ਹਾਂ?

ਅਸੀਂ ਬ੍ਰਾਂਚ ਦੀ ਆਖਰੀ ਕਮਿਟ 'ਤੇ ਬਿਲਡ ਸ਼ੁਰੂ ਕੀਤਾ ਜਿੱਥੋਂ ਪੁੱਲ ਬੇਨਤੀ ਖੋਲ੍ਹੀ ਗਈ ਸੀ। ਪਰ ਇਸ ਪ੍ਰਤੀਬੱਧਤਾ ਦੇ ਟੈਸਟ ਸਿਰਫ ਇਹ ਦਿਖਾ ਸਕਦੇ ਹਨ ਕਿ ਡਿਵੈਲਪਰ ਦੁਆਰਾ ਲਿਖਿਆ ਕੋਡ ਕੰਮ ਕਰਦਾ ਹੈ। ਪਰ ਉਹ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੇ ਕਿ ਉਸਨੇ ਕੁਝ ਵੀ ਨਹੀਂ ਤੋੜਿਆ। ਵਾਸਤਵ ਵਿੱਚ, ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਇਸ ਵਿੱਚ ਮਿਲਾਉਣ ਤੋਂ ਬਾਅਦ ਤੁਹਾਨੂੰ ਵਿਕਾਸ ਸ਼ਾਖਾ ਦੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਅਜਿਹਾ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਸਧਾਰਨ ਬੈਸ਼ ਸਕ੍ਰਿਪਟ ਲਿਖੀ ਹੈ premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

ਇੱਥੇ ਵਿਕਾਸ ਦੇ ਸਾਰੇ ਨਵੀਨਤਮ ਬਦਲਾਵਾਂ ਨੂੰ ਬਸ ਖਿੱਚਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਮੌਜੂਦਾ ਸ਼ਾਖਾ ਵਿੱਚ ਮਿਲਾਇਆ ਜਾਂਦਾ ਹੈ। ਅਸੀਂ premerge.sh ਸਕ੍ਰਿਪਟ ਨੂੰ ਸਾਰੇ ਬਿਲਡਾਂ ਵਿੱਚ ਪਹਿਲੇ ਪੜਾਅ ਵਜੋਂ ਜੋੜਿਆ ਹੈ ਅਤੇ ਇਹ ਦੇਖਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਹੈ ਕਿ ਅਸੀਂ ਕੀ ਚਾਹੁੰਦੇ ਹਾਂ, ਉਹ ਹੈ ਏਕੀਕਰਣ.

ਸਮੱਸਿਆ ਨੂੰ ਸਥਾਨਕ ਬਣਾਉਣ, ਹੱਲ ਲੱਭਣ ਅਤੇ ਇਸ ਸਕ੍ਰਿਪਟ ਨੂੰ ਲਿਖਣ ਵਿੱਚ ਤਿੰਨ ਦਿਨ ਲੱਗ ਗਏ।

ਐਪਲੀਕੇਸ਼ਨ ਵਿਕਸਿਤ ਹੋਈ, ਜ਼ਿਆਦਾ ਤੋਂ ਜ਼ਿਆਦਾ ਕੰਮ ਦਿਖਾਈ ਦਿੱਤੇ, ਟੀਮ ਵਧਦੀ ਗਈ, ਅਤੇ premerge.sh ਨੇ ਕਈ ਵਾਰ ਸਾਨੂੰ ਨਿਰਾਸ਼ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਵਿਕਾਸ ਵਿੱਚ ਵਿਵਾਦਪੂਰਨ ਤਬਦੀਲੀਆਂ ਸਨ ਜੋ ਬਿਲਡ ਨੂੰ ਤੋੜ ਦਿੰਦੀਆਂ ਹਨ।

ਇਹ ਕਿਵੇਂ ਵਾਪਰਦਾ ਹੈ ਦੀ ਇੱਕ ਉਦਾਹਰਨ:

ਦੋ ਡਿਵੈਲਪਰ ਇੱਕੋ ਸਮੇਂ A ਅਤੇ B ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ 'ਤੇ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ। ਵਿਸ਼ੇਸ਼ਤਾ A ਦੇ ਡਿਵੈਲਪਰ ਨੂੰ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਇੱਕ ਅਣਵਰਤੀ ਵਿਸ਼ੇਸ਼ਤਾ ਦਾ ਪਤਾ ਲੱਗਦਾ ਹੈ। answer() ਅਤੇ, ਇੱਕ ਚੰਗੇ ਲੜਕੇ ਸਕਾਊਟ ਵਾਂਗ, ਇਸਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹੈ। ਇਸ ਦੇ ਨਾਲ ਹੀ, ਫੀਚਰ ਬੀ ਦੇ ਡਿਵੈਲਪਰ ਨੇ ਆਪਣੀ ਬ੍ਰਾਂਚ ਵਿੱਚ ਇਸ ਫੰਕਸ਼ਨ ਲਈ ਇੱਕ ਨਵੀਂ ਕਾਲ ਸ਼ਾਮਲ ਕੀਤੀ।

ਡਿਵੈਲਪਰ ਆਪਣਾ ਕੰਮ ਪੂਰਾ ਕਰਦੇ ਹਨ ਅਤੇ ਉਸੇ ਸਮੇਂ ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ ਖੋਲ੍ਹਦੇ ਹਨ. ਬਿਲਡ ਲਾਂਚ ਕੀਤੇ ਗਏ ਹਨ, premerge.sh ਨਵੀਨਤਮ ਵਿਕਾਸ ਸਥਿਤੀ ਦੇ ਸੰਬੰਧ ਵਿੱਚ ਦੋਨੋ ਪੁੱਲ ਬੇਨਤੀਆਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ - ਸਾਰੀਆਂ ਜਾਂਚਾਂ ਹਰੇ ਹਨ। ਉਸ ਤੋਂ ਬਾਅਦ, ਵਿਸ਼ੇਸ਼ਤਾ A ਦੀ ਪੁੱਲ ਬੇਨਤੀ ਨੂੰ ਮਿਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਵਿਸ਼ੇਸ਼ਤਾ B ਦੀ ਪੁੱਲ ਬੇਨਤੀ ਨੂੰ ਮਿਲਾਇਆ ਜਾਂਦਾ ਹੈ... ਬੂਮ! ਡਿਵੈਲਪ ਬ੍ਰੇਕਸ ਕਿਉਂਕਿ ਡਿਵੈਲਪ ਕੋਡ ਵਿੱਚ ਇੱਕ ਗੈਰ-ਮੌਜੂਦ ਫੰਕਸ਼ਨ ਲਈ ਕਾਲ ਹੁੰਦੀ ਹੈ।

ਜਦੋਂ ਇਹ ਵਿਕਸਤ ਨਹੀਂ ਹੋਣ ਵਾਲਾ ਹੈ, ਇਹ ਹੈ ਸਥਾਨਕ ਆਫ਼ਤ. ਪੂਰੀ ਟੀਮ ਕੁਝ ਵੀ ਇਕੱਠਾ ਨਹੀਂ ਕਰ ਸਕਦੀ ਅਤੇ ਜਾਂਚ ਲਈ ਜਮ੍ਹਾਂ ਨਹੀਂ ਕਰ ਸਕਦੀ।

ਅਜਿਹਾ ਹੋਇਆ ਕਿ ਮੈਂ ਅਕਸਰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਕੰਮਾਂ 'ਤੇ ਕੰਮ ਕੀਤਾ: ਵਿਸ਼ਲੇਸ਼ਣ, ਨੈੱਟਵਰਕ, ਡਾਟਾਬੇਸ। ਭਾਵ, ਇਹ ਮੈਂ ਸੀ ਜਿਸਨੇ ਉਹ ਫੰਕਸ਼ਨ ਅਤੇ ਕਲਾਸਾਂ ਲਿਖੀਆਂ ਜੋ ਦੂਜੇ ਡਿਵੈਲਪਰ ਵਰਤਦੇ ਹਨ। ਇਸ ਕਰਕੇ, ਮੈਂ ਆਪਣੇ ਆਪ ਨੂੰ ਅਕਸਰ ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਪਾਇਆ. ਮੇਰੇ ਕੋਲ ਇਹ ਤਸਵੀਰ ਕੁਝ ਸਮੇਂ ਲਈ ਲਟਕ ਗਈ ਸੀ.

ਕਿਉਂਕਿ ਇਹ ਸਾਡੇ ਅਨੁਕੂਲ ਨਹੀਂ ਸੀ, ਅਸੀਂ ਇਸ ਨੂੰ ਰੋਕਣ ਦੇ ਵਿਕਲਪਾਂ ਦੀ ਪੜਚੋਲ ਕਰਨੀ ਸ਼ੁਰੂ ਕੀਤੀ।

ਵਿਕਾਸ ਨੂੰ ਕਿਵੇਂ ਨਹੀਂ ਤੋੜਨਾ ਹੈ

ਪਹਿਲਾ ਵਿਕਲਪ: ਡਿਵੈਲਪ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਵੇਲੇ ਸਾਰੀਆਂ ਪੁੱਲ ਬੇਨਤੀਆਂ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਓ। ਜੇਕਰ, ਸਾਡੀ ਉਦਾਹਰਨ ਵਿੱਚ, ਵਿਸ਼ੇਸ਼ਤਾ A ਦੇ ਨਾਲ ਪੁੱਲ ਬੇਨਤੀ ਵਿਕਾਸ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਹੈ, ਤਾਂ ਵਿਸ਼ੇਸ਼ਤਾ B ਦੀ ਪੁੱਲ ਬੇਨਤੀ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਇਆ ਜਾਵੇਗਾ, ਅਤੇ, ਇਸਦੇ ਅਨੁਸਾਰ, ਇੱਕ ਸੰਕਲਨ ਗਲਤੀ ਦੇ ਕਾਰਨ ਜਾਂਚਾਂ ਅਸਫਲ ਹੋ ਜਾਣਗੀਆਂ।

ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਇਸ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗੇਗਾ, ਦੋ PR ਦੇ ਨਾਲ ਇੱਕ ਉਦਾਹਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰੋ। ਅਸੀਂ ਦੋ ਪੀਆਰ ਖੋਲ੍ਹਦੇ ਹਾਂ: ਦੋ ਬਿਲਡ, ਦੋ ਰਨ ਆਫ ਚੈਕ। ਪਹਿਲੀ PR ਨੂੰ ਵਿਕਾਸ ਵਿੱਚ ਮਿਲਾਉਣ ਤੋਂ ਬਾਅਦ, ਦੂਜੇ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਕੁੱਲ ਮਿਲਾ ਕੇ, ਦੋ PR ਲਈ ਤਿੰਨ ਦੌੜਾਂ ਦੀ ਜਾਂਚ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: 2 + 1 = 3।

ਸਿਧਾਂਤ ਵਿੱਚ, ਇਹ ਠੀਕ ਹੈ. ਪਰ ਅਸੀਂ ਅੰਕੜਿਆਂ ਨੂੰ ਦੇਖਿਆ, ਅਤੇ ਸਾਡੀ ਟੀਮ ਵਿੱਚ ਆਮ ਸਥਿਤੀ 10 ਓਪਨ ਪੀਆਰ ਸੀ, ਅਤੇ ਫਿਰ ਚੈਕਾਂ ਦੀ ਗਿਣਤੀ ਤਰੱਕੀ ਦਾ ਜੋੜ ਹੈ: 10 + 9 +... + 1 = 55. ਭਾਵ, 10 ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ PRs, ਤੁਹਾਨੂੰ 55 ਵਾਰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਅਤੇ ਇਹ ਇੱਕ ਆਦਰਸ਼ ਸਥਿਤੀ ਵਿੱਚ ਹੈ, ਜਦੋਂ ਸਾਰੀਆਂ ਜਾਂਚਾਂ ਪਹਿਲੀ ਵਾਰ ਪਾਸ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਜਦੋਂ ਕੋਈ ਵੀ ਵਾਧੂ ਪੁੱਲ ਬੇਨਤੀ ਨਹੀਂ ਖੋਲ੍ਹਦਾ ਹੈ ਜਦੋਂ ਕਿ ਇਹਨਾਂ ਦਰਜਨਾਂ 'ਤੇ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ।

ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਡਿਵੈਲਪਰ ਦੇ ਰੂਪ ਵਿੱਚ ਕਲਪਨਾ ਕਰੋ ਜਿਸਨੂੰ "ਅਭੇਦ" ਬਟਨ 'ਤੇ ਕਲਿੱਕ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਹੋਣ ਦੀ ਲੋੜ ਹੈ, ਕਿਉਂਕਿ ਜੇਕਰ ਕੋਈ ਗੁਆਂਢੀ ਅਜਿਹਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਦੋਂ ਤੱਕ ਉਡੀਕ ਕਰਨੀ ਪਵੇਗੀ ਜਦੋਂ ਤੱਕ ਸਾਰੇ ਬਿਲਡ ਦੁਬਾਰਾ ਨਹੀਂ ਹੋ ਜਾਂਦੇ... ਨਹੀਂ, ਇਹ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ , ਇਹ ਵਿਕਾਸ ਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਹੌਲੀ ਕਰ ਦੇਵੇਗਾ।

ਦੂਜਾ ਸੰਭਵ ਤਰੀਕਾ: ਕੋਡ ਸਮੀਖਿਆ ਤੋਂ ਬਾਅਦ ਪੁੱਲ ਬੇਨਤੀਆਂ ਨੂੰ ਇਕੱਠਾ ਕਰੋ। ਭਾਵ, ਤੁਸੀਂ ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ ਖੋਲ੍ਹਦੇ ਹੋ, ਸਹਿਕਰਮੀਆਂ ਤੋਂ ਲੋੜੀਂਦੀਆਂ ਮਨਜ਼ੂਰੀਆਂ ਇਕੱਠੀਆਂ ਕਰਦੇ ਹੋ, ਜੋ ਲੋੜੀਂਦਾ ਹੈ ਉਸ ਨੂੰ ਠੀਕ ਕਰੋ, ਅਤੇ ਫਿਰ ਬਿਲਡ ਲਾਂਚ ਕਰੋ। ਜੇਕਰ ਉਹ ਸਫਲ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਪੁੱਲ ਬੇਨਤੀ ਨੂੰ ਵਿਕਾਸ ਵਿੱਚ ਮਿਲਾਇਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਕੋਈ ਵਾਧੂ ਰੀਸਟਾਰਟ ਨਹੀਂ ਹੁੰਦੇ ਹਨ, ਪਰ ਫੀਡਬੈਕ ਬਹੁਤ ਹੌਲੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਡਿਵੈਲਪਰ ਵਜੋਂ, ਜਦੋਂ ਮੈਂ ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ ਖੋਲ੍ਹਦਾ ਹਾਂ, ਮੈਂ ਤੁਰੰਤ ਇਹ ਦੇਖਣਾ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਕੀ ਇਹ ਕੰਮ ਕਰਨ ਜਾ ਰਿਹਾ ਹੈ. ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਕੋਈ ਟੈਸਟ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਜਲਦੀ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਇੱਕ ਦੇਰੀ ਨਾਲ ਬਿਲਡ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਫੀਡਬੈਕ ਹੌਲੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇਸਲਈ ਪੂਰਾ ਵਿਕਾਸ. ਇਹ ਸਾਡੇ ਲਈ ਵੀ ਠੀਕ ਨਹੀਂ ਸੀ।

ਨਤੀਜੇ ਵਜੋਂ, ਸਿਰਫ ਤੀਜਾ ਵਿਕਲਪ ਬਚਿਆ - ਸਾਈਕਲ. ਸਾਡੇ ਸਾਰੇ ਕੋਡ, ਸਾਡੇ ਸਾਰੇ ਸਰੋਤ ਬਿੱਟਬਕੇਟ ਸਰਵਰ 'ਤੇ ਇੱਕ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਇਸ ਅਨੁਸਾਰ, ਸਾਨੂੰ ਬਿੱਟਬਕੇਟ ਲਈ ਇੱਕ ਪਲੱਗਇਨ ਵਿਕਸਿਤ ਕਰਨਾ ਪਿਆ।

ਇਹ ਪਲੱਗਇਨ ਪੁੱਲ ਬੇਨਤੀ ਵਿਲੀਨ ਵਿਧੀ ਨੂੰ ਓਵਰਰਾਈਡ ਕਰਦੀ ਹੈ। ਸ਼ੁਰੂਆਤ ਮਿਆਰੀ ਹੈ: PR ਖੁੱਲ੍ਹਦਾ ਹੈ, ਸਾਰੀਆਂ ਅਸੈਂਬਲੀਆਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ, ਕੋਡ ਸਮੀਖਿਆ ਪੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਪਰ ਕੋਡ ਸਮੀਖਿਆ ਪੂਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ ਅਤੇ ਡਿਵੈਲਪਰ "ਮਿਲਣ" 'ਤੇ ਕਲਿੱਕ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰਦਾ ਹੈ, ਪਲੱਗਇਨ ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਕਿਸ ਵਿਕਾਸ ਰਾਜ ਦੇ ਵਿਰੁੱਧ ਚੈਕ ਚਲਾਇਆ ਗਿਆ ਸੀ। ਜੇਕਰ ਵਿਕਾਸ ਨੂੰ ਬਿਲਡ ਤੋਂ ਬਾਅਦ ਅੱਪਡੇਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਪਲੱਗਇਨ ਅਜਿਹੀ ਪੁੱਲ ਬੇਨਤੀ ਨੂੰ ਮੁੱਖ ਸ਼ਾਖਾ ਵਿੱਚ ਮਿਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦੇਵੇਗੀ। ਇਹ ਬਸ ਇੱਕ ਮੁਕਾਬਲਤਨ ਹਾਲੀਆ ਵਿਕਾਸ ਦੇ ਬਿਲਡ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰੇਗਾ.

ਵਿਰੋਧੀ ਤਬਦੀਲੀਆਂ ਦੇ ਨਾਲ ਸਾਡੀ ਉਦਾਹਰਨ ਵਿੱਚ, ਅਜਿਹੇ ਬਿਲਡ ਇੱਕ ਸੰਕਲਨ ਗਲਤੀ ਦੇ ਕਾਰਨ ਅਸਫਲ ਹੋ ਜਾਣਗੇ। ਇਸ ਅਨੁਸਾਰ, ਵਿਸ਼ੇਸ਼ਤਾ ਬੀ ਦੇ ਡਿਵੈਲਪਰ ਨੂੰ ਕੋਡ ਨੂੰ ਠੀਕ ਕਰਨਾ ਹੋਵੇਗਾ, ਜਾਂਚਾਂ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨਾ ਹੋਵੇਗਾ, ਫਿਰ ਪਲੱਗਇਨ ਆਪਣੇ ਆਪ ਪੁੱਲ ਬੇਨਤੀ ਨੂੰ ਲਾਗੂ ਕਰੇਗਾ।

ਇਸ ਪਲੱਗਇਨ ਨੂੰ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਪ੍ਰਤੀ ਪੁੱਲ ਬੇਨਤੀ ਦੀ ਔਸਤ 2,7 ਸਮੀਖਿਆ ਕੀਤੀ। ਪਲੱਗਇਨ ਦੇ ਨਾਲ 3,6 ਲਾਂਚ ਹੋਏ. ਇਹ ਸਾਡੇ ਲਈ ਅਨੁਕੂਲ ਸੀ.

ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਇਸ ਪਲੱਗਇਨ ਵਿੱਚ ਇੱਕ ਕਮੀ ਹੈ: ਇਹ ਸਿਰਫ ਇੱਕ ਵਾਰ ਬਿਲਡ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਦਾ ਹੈ। ਭਾਵ, ਅਜੇ ਵੀ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਵਿੰਡੋ ਹੈ ਜਿਸ ਰਾਹੀਂ ਵਿਰੋਧੀ ਤਬਦੀਲੀਆਂ ਵਿਕਸਿਤ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਪਰ ਇਸਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੈ, ਅਤੇ ਅਸੀਂ ਸ਼ੁਰੂਆਤ ਦੀ ਸੰਖਿਆ ਅਤੇ ਅਸਫਲਤਾ ਦੀ ਸੰਭਾਵਨਾ ਦੇ ਵਿਚਕਾਰ ਇਹ ਵਪਾਰ ਕੀਤਾ ਹੈ। ਦੋ ਸਾਲਾਂ ਵਿੱਚ ਇਹ ਸਿਰਫ ਇੱਕ ਵਾਰ ਫਾਇਰ ਹੋਇਆ, ਇਸ ਲਈ ਇਹ ਸ਼ਾਇਦ ਵਿਅਰਥ ਨਹੀਂ ਸੀ।

ਬਿੱਟਬਕੇਟ ਪਲੱਗਇਨ ਦਾ ਪਹਿਲਾ ਸੰਸਕਰਣ ਲਿਖਣ ਵਿੱਚ ਸਾਨੂੰ ਦੋ ਹਫ਼ਤੇ ਲੱਗ ਗਏ।

ਨਵੀਆਂ ਜਾਂਚਾਂ

ਇਸ ਦੌਰਾਨ ਸਾਡੀ ਟੀਮ ਵਧਦੀ ਰਹੀ। ਨਵੇਂ ਚੈੱਕ ਜੋੜੇ ਗਏ ਹਨ।

ਅਸੀਂ ਸੋਚਿਆ: ਜੇ ਉਹਨਾਂ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ ਤਾਂ ਗਲਤੀਆਂ ਕਿਉਂ ਕਰੀਏ? ਅਤੇ ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਨੇ ਲਾਗੂ ਕੀਤਾ ਸਥਿਰ ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਣ. ਅਸੀਂ lint ਨਾਲ ਸ਼ੁਰੂਆਤ ਕੀਤੀ, ਜੋ ਕਿ Android SDK ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ। ਪਰ ਉਸ ਸਮੇਂ ਉਸਨੂੰ ਇਹ ਨਹੀਂ ਪਤਾ ਸੀ ਕਿ ਕੋਟਲਿਨ ਕੋਡ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ, ਅਤੇ ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਕੋਟਲਿਨ ਵਿੱਚ 75% ਐਪਲੀਕੇਸ਼ਨ ਲਿਖੀ ਹੋਈ ਸੀ। ਇਸ ਲਈ, ਬਿਲਟ-ਇਨ ਨੂੰ ਲਿੰਟ ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਸੀ ਐਂਡਰਾਇਡ ਸਟੂਡੀਓ ਜਾਂਚ ਕਰਦਾ ਹੈ।

ਅਜਿਹਾ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਬਹੁਤ ਸਾਰਾ ਵਿਗਾੜ ਕਰਨਾ ਪਿਆ: ਐਂਡਰੌਇਡ ਸਟੂਡੀਓ ਲਓ, ਇਸਨੂੰ ਡੌਕਰ ਵਿੱਚ ਪੈਕ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਵਰਚੁਅਲ ਮਾਨੀਟਰ ਨਾਲ CI 'ਤੇ ਚਲਾਓ, ਤਾਂ ਜੋ ਇਹ ਸੋਚੇ ਕਿ ਇਹ ਅਸਲ ਲੈਪਟਾਪ 'ਤੇ ਚੱਲ ਰਿਹਾ ਹੈ। ਪਰ ਇਹ ਕੰਮ ਕੀਤਾ.

ਇਸ ਸਮੇਂ ਦੌਰਾਨ ਅਸੀਂ ਬਹੁਤ ਕੁਝ ਲਿਖਣਾ ਵੀ ਸ਼ੁਰੂ ਕੀਤਾ ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ ਟੈਸਟ ਅਤੇ ਲਾਗੂ ਕੀਤਾ ਸਕ੍ਰੀਨਸ਼ਾਟ ਟੈਸਟਿੰਗ. ਇਹ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਵੱਖਰੇ ਛੋਟੇ ਦ੍ਰਿਸ਼ ਲਈ ਇੱਕ ਸੰਦਰਭ ਸਕ੍ਰੀਨਸ਼ੌਟ ਤਿਆਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਟੈਸਟ ਵਿੱਚ ਦ੍ਰਿਸ਼ ਤੋਂ ਇੱਕ ਸਕ੍ਰੀਨਸ਼ੌਟ ਲੈਣਾ ਅਤੇ ਪਿਕਸਲ ਦੁਆਰਾ ਸਿੱਧੇ ਪਿਕਸਲ ਨਾਲ ਇਸਦੀ ਤੁਲਨਾ ਕਰਨਾ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਫਰਕ ਹੈ, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਲੇਆਉਟ ਕਿਤੇ ਗਲਤ ਹੋ ਗਿਆ ਹੈ ਜਾਂ ਸ਼ੈਲੀ ਵਿੱਚ ਕੁਝ ਗਲਤ ਹੈ.

ਪਰ ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ ਟੈਸਟਾਂ ਅਤੇ ਸਕ੍ਰੀਨਸ਼ੌਟ ਟੈਸਟਾਂ ਨੂੰ ਡਿਵਾਈਸਾਂ 'ਤੇ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਇਮੂਲੇਟਰਾਂ ਜਾਂ ਅਸਲ ਡਿਵਾਈਸਾਂ 'ਤੇ। ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਕਿ ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਟੈਸਟ ਹਨ ਅਤੇ ਉਹ ਅਕਸਰ ਚਲਾਏ ਜਾਂਦੇ ਹਨ, ਇੱਕ ਪੂਰੇ ਫਾਰਮ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਆਪਣਾ ਖੁਦ ਦਾ ਫਾਰਮ ਸ਼ੁਰੂ ਕਰਨਾ ਬਹੁਤ ਮਿਹਨਤੀ ਹੈ, ਇਸਲਈ ਸਾਨੂੰ ਇੱਕ ਤਿਆਰ ਵਿਕਲਪ ਮਿਲਿਆ - ਫਾਇਰਬੇਸ ਟੈਸਟ ਲੈਬ।

ਫਾਇਰਬੇਸ ਟੈਸਟ ਲੈਬ

ਇਹ ਇਸ ਲਈ ਚੁਣਿਆ ਗਿਆ ਸੀ ਕਿਉਂਕਿ ਫਾਇਰਬੇਸ ਇੱਕ Google ਉਤਪਾਦ ਹੈ, ਭਾਵ ਇਹ ਭਰੋਸੇਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕਦੇ ਵੀ ਮਰਨ ਦੀ ਸੰਭਾਵਨਾ ਨਹੀਂ ਹੈ। ਕੀਮਤਾਂ ਵਾਜਬ ਹਨ: ਇੱਕ ਅਸਲੀ ਡਿਵਾਈਸ ਦੇ ਸੰਚਾਲਨ ਲਈ $5 ਪ੍ਰਤੀ ਘੰਟਾ, ਇੱਕ ਇਮੂਲੇਟਰ ਦੇ ਸੰਚਾਲਨ ਲਈ 1 $ ਪ੍ਰਤੀ ਘੰਟਾ।

ਸਾਡੇ CI ਵਿੱਚ ਫਾਇਰਬੇਸ ਟੈਸਟ ਲੈਬ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਲਗਭਗ ਤਿੰਨ ਹਫ਼ਤੇ ਲੱਗ ਗਏ।

ਪਰ ਟੀਮ ਵਧਦੀ ਰਹੀ, ਅਤੇ ਫਾਇਰਬੇਸ, ਬਦਕਿਸਮਤੀ ਨਾਲ, ਸਾਨੂੰ ਨਿਰਾਸ਼ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਉਸ ਸਮੇਂ ਉਨ੍ਹਾਂ ਕੋਲ ਕੋਈ ਐਸ.ਐਲ.ਏ. ਕਈ ਵਾਰ ਫਾਇਰਬੇਸ ਨੇ ਸਾਨੂੰ ਟੈਸਟਾਂ ਲਈ ਲੋੜੀਂਦੇ ਡਿਵਾਈਸਾਂ ਦੇ ਮੁਫਤ ਹੋਣ ਤੱਕ ਉਡੀਕ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕੀਤਾ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਤੁਰੰਤ ਲਾਗੂ ਕਰਨਾ ਸ਼ੁਰੂ ਨਹੀਂ ਕੀਤਾ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਚਾਹੁੰਦੇ ਸੀ। ਲਾਈਨ ਵਿੱਚ ਇੰਤਜ਼ਾਰ ਕਰਨ ਵਿੱਚ ਅੱਧਾ ਘੰਟਾ ਲੱਗ ਗਿਆ, ਜੋ ਕਿ ਬਹੁਤ ਲੰਬਾ ਸਮਾਂ ਹੈ। ਹਰ PR 'ਤੇ ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ ਟੈਸਟ ਚਲਾਏ ਗਏ ਸਨ, ਦੇਰੀ ਨੇ ਅਸਲ ਵਿੱਚ ਵਿਕਾਸ ਨੂੰ ਹੌਲੀ ਕਰ ਦਿੱਤਾ, ਅਤੇ ਫਿਰ ਮਹੀਨਾਵਾਰ ਬਿੱਲ ਇੱਕ ਗੋਲ ਰਕਮ ਦੇ ਨਾਲ ਆਇਆ। ਆਮ ਤੌਰ 'ਤੇ, ਫਾਇਰਬੇਸ ਨੂੰ ਛੱਡਣ ਅਤੇ ਘਰ-ਘਰ ਕੰਮ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਗਿਆ ਸੀ, ਕਿਉਂਕਿ ਟੀਮ ਕਾਫ਼ੀ ਵਧ ਗਈ ਸੀ।

ਡੌਕਰ + ਪਾਈਥਨ + ਬੈਸ਼

ਅਸੀਂ ਡੌਕਰ, ਸਟੱਫਡ ਇਮੂਲੇਟਰਾਂ ਨੂੰ ਇਸ ਵਿੱਚ ਲਿਆ, ਪਾਈਥਨ ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ ਪ੍ਰੋਗਰਾਮ ਲਿਖਿਆ, ਜੋ ਸਹੀ ਸਮੇਂ 'ਤੇ ਲੋੜੀਂਦੇ ਸੰਸਕਰਣ ਵਿੱਚ ਇਮੂਲੇਟਰਾਂ ਦੀ ਲੋੜੀਂਦੀ ਗਿਣਤੀ ਲਿਆਉਂਦਾ ਹੈ ਅਤੇ ਲੋੜ ਪੈਣ 'ਤੇ ਉਹਨਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ। ਅਤੇ, ਬੇਸ਼ਕ, ਬੈਸ਼ ਸਕ੍ਰਿਪਟਾਂ ਦੇ ਇੱਕ ਜੋੜੇ - ਅਸੀਂ ਉਹਨਾਂ ਤੋਂ ਬਿਨਾਂ ਕਿੱਥੇ ਹੋਵਾਂਗੇ?

ਸਾਡੇ ਆਪਣੇ ਟੈਸਟ ਦਾ ਮਾਹੌਲ ਬਣਾਉਣ ਵਿੱਚ ਪੰਜ ਹਫ਼ਤੇ ਲੱਗ ਗਏ।

ਨਤੀਜੇ ਵਜੋਂ, ਹਰੇਕ ਪੁੱਲ ਬੇਨਤੀ ਲਈ ਚੈਕਾਂ ਦੀ ਇੱਕ ਵਿਆਪਕ ਅਭੇਦ-ਬਲੌਕਿੰਗ ਸੂਚੀ ਸੀ:

• ARK ਅਸੈਂਬਲੀ;
• ਜੂਨਿਟ ਟੈਸਟ;
• ਲਿੰਟ;
• ਐਂਡਰੌਇਡ ਸਟੂਡੀਓ ਜਾਂਚ;
• ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ ਟੈਸਟ;
• ਸਕ੍ਰੀਨਸ਼ਾਟ ਟੈਸਟ।

ਇਸ ਨਾਲ ਬਹੁਤ ਸਾਰੇ ਸੰਭਾਵੀ ਟੁੱਟਣ ਨੂੰ ਰੋਕਿਆ ਗਿਆ। ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸਭ ਕੁਝ ਕੰਮ ਕੀਤਾ, ਪਰ ਡਿਵੈਲਪਰਾਂ ਨੇ ਸ਼ਿਕਾਇਤ ਕੀਤੀ ਕਿ ਨਤੀਜਿਆਂ ਦੀ ਉਡੀਕ ਬਹੁਤ ਲੰਮੀ ਸੀ.

ਕਿੰਨਾ ਸਮਾਂ ਬਹੁਤ ਲੰਬਾ ਹੈ? ਅਸੀਂ Bitbucket ਅਤੇ TeamCity ਤੋਂ ਡੇਟਾ ਨੂੰ ਵਿਸ਼ਲੇਸ਼ਣ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਅੱਪਲੋਡ ਕੀਤਾ ਹੈ ਅਤੇ ਇਹ ਮਹਿਸੂਸ ਕੀਤਾ ਹੈ ਔਸਤ ਉਡੀਕ ਸਮਾਂ 45 ਮਿੰਟ. ਭਾਵ, ਇੱਕ ਡਿਵੈਲਪਰ, ਜਦੋਂ ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ ਨੂੰ ਖੋਲ੍ਹਦਾ ਹੈ, ਬਿਲਡ ਨਤੀਜਿਆਂ ਲਈ ਔਸਤਨ 45 ਮਿੰਟ ਉਡੀਕ ਕਰਦਾ ਹੈ। ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਇਹ ਬਹੁਤ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦੇ।

ਬੇਸ਼ੱਕ, ਅਸੀਂ ਆਪਣੀਆਂ ਸਾਰੀਆਂ ਬਿਲਡਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।

ਚਲੋ ਤੇਜ਼ ਕਰੀਏ

ਇਹ ਦੇਖਦੇ ਹੋਏ ਕਿ ਬਿਲਡਜ਼ ਅਕਸਰ ਇੱਕ ਕਤਾਰ ਵਿੱਚ ਖੜ੍ਹੇ ਹੁੰਦੇ ਹਨ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਅਸੀਂ ਕਰਦੇ ਹਾਂ ਹੋਰ ਹਾਰਡਵੇਅਰ ਖਰੀਦਿਆ - ਵਿਆਪਕ ਵਿਕਾਸ ਸਭ ਤੋਂ ਸਰਲ ਹੈ। ਬਿਲਡਾਂ ਨੇ ਕਤਾਰ ਲਗਾਉਣੀ ਬੰਦ ਕਰ ਦਿੱਤੀ, ਪਰ ਉਡੀਕ ਸਮਾਂ ਥੋੜ੍ਹਾ ਜਿਹਾ ਘਟਿਆ, ਕਿਉਂਕਿ ਕੁਝ ਜਾਂਚਾਂ ਨੇ ਆਪਣੇ ਆਪ ਵਿੱਚ ਬਹੁਤ ਲੰਬਾ ਸਮਾਂ ਲਿਆ।

ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੈਣ ਵਾਲੇ ਚੈਕਾਂ ਨੂੰ ਹਟਾਇਆ ਜਾ ਰਿਹਾ ਹੈ

ਸਾਡਾ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਇਸ ਕਿਸਮ ਦੀਆਂ ਗਲਤੀਆਂ ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਫੜ ਸਕਦਾ ਹੈ।

• ਨਹੀਂ ਜਾ ਰਿਹਾ. ਸੀਆਈ ਇੱਕ ਸੰਕਲਨ ਗਲਤੀ ਨੂੰ ਫੜ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕੁਝ ਵਿਰੋਧੀ ਤਬਦੀਲੀਆਂ ਕਾਰਨ ਨਹੀਂ ਬਣਦਾ ਹੈ। ਜਿਵੇਂ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਕਿਹਾ ਸੀ, ਫਿਰ ਕੋਈ ਵੀ ਕੁਝ ਨਹੀਂ ਇਕੱਠਾ ਕਰ ਸਕਦਾ, ਵਿਕਾਸ ਰੁਕ ਜਾਂਦਾ ਹੈ ਅਤੇ ਹਰ ਕੋਈ ਘਬਰਾ ਜਾਂਦਾ ਹੈ।
• ਵਿਹਾਰ ਵਿੱਚ ਬੱਗ. ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਈ ਜਾਂਦੀ ਹੈ, ਪਰ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਬਟਨ ਦਬਾਉਂਦੇ ਹੋ ਤਾਂ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਬਟਨ ਨੂੰ ਬਿਲਕੁਲ ਨਹੀਂ ਦਬਾਇਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਬੁਰਾ ਹੈ ਕਿਉਂਕਿ ਅਜਿਹਾ ਬੱਗ ਉਪਭੋਗਤਾ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ।
• ਖਾਕਾ ਵਿੱਚ ਬੱਗ. ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਬਟਨ ਨੂੰ ਕਲਿੱਕ ਕੀਤਾ ਗਿਆ ਹੈ, ਪਰ 10 ਪਿਕਸਲ ਨੂੰ ਖੱਬੇ ਪਾਸੇ ਲਿਜਾਇਆ ਗਿਆ ਹੈ।
• ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਵਿੱਚ ਵਾਧਾ.

ਇਸ ਸੂਚੀ ਨੂੰ ਦੇਖਣ ਤੋਂ ਬਾਅਦ, ਸਾਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਸਿਰਫ਼ ਪਹਿਲੇ ਦੋ ਅੰਕ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਅਸੀਂ ਪਹਿਲਾਂ ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਫੜਨਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਲੇਆਉਟ ਵਿੱਚ ਬੱਗ ਡਿਜ਼ਾਈਨ-ਸਮੀਖਿਆ ਪੜਾਅ 'ਤੇ ਖੋਜੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਫਿਰ ਆਸਾਨੀ ਨਾਲ ਠੀਕ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਨਾਲ ਨਜਿੱਠਣ ਲਈ ਇੱਕ ਵੱਖਰੀ ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਯੋਜਨਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਅਸੀਂ ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ 'ਤੇ ਇਸਦੀ ਜਾਂਚ ਨਾ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।

ਇਸ ਵਰਗੀਕਰਨ ਦੇ ਆਧਾਰ 'ਤੇ, ਅਸੀਂ ਜਾਂਚਾਂ ਦੀ ਪੂਰੀ ਸੂਚੀ ਨੂੰ ਹਿਲਾ ਦਿੱਤਾ ਹੈ। ਲਿੰਟ ਨੂੰ ਪਾਰ ਕੀਤਾ ਅਤੇ ਇਸਦੀ ਲਾਂਚਿੰਗ ਨੂੰ ਰਾਤੋ-ਰਾਤ ਮੁਲਤਵੀ ਕਰ ਦਿੱਤਾ: ਸਿਰਫ ਇਸ ਲਈ ਕਿ ਇਹ ਇਸ ਗੱਲ ਦੀ ਰਿਪੋਰਟ ਤਿਆਰ ਕਰੇ ਕਿ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਕਿੰਨੀਆਂ ਸਮੱਸਿਆਵਾਂ ਸਨ। ਅਸੀਂ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਦੇ ਨਾਲ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਨ ਲਈ ਸਹਿਮਤ ਹੋਏ, ਅਤੇ ਐਂਡਰਾਇਡ ਸਟੂਡੀਓ ਜਾਂਚਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡ ਦਿੱਤਾ ਗਿਆ ਸੀ. ਰਨਿੰਗ ਇੰਸਪੈਕਸ਼ਨਾਂ ਲਈ ਡੌਕਰ ਵਿੱਚ ਐਂਡਰੌਇਡ ਸਟੂਡੀਓ ਦਿਲਚਸਪ ਲੱਗਦਾ ਹੈ, ਪਰ ਸਮਰਥਨ ਵਿੱਚ ਬਹੁਤ ਪਰੇਸ਼ਾਨੀ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ। ਐਂਡਰੌਇਡ ਸਟੂਡੀਓ ਸੰਸਕਰਣਾਂ ਦੇ ਕਿਸੇ ਵੀ ਅੱਪਡੇਟ ਦਾ ਮਤਲਬ ਸਮਝ ਤੋਂ ਬਾਹਰ ਬੱਗ ਨਾਲ ਸੰਘਰਸ਼ ਕਰਨਾ ਹੈ। ਸਕ੍ਰੀਨਸ਼ਾਟ ਟੈਸਟਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਵੀ ਮੁਸ਼ਕਲ ਸੀ, ਕਿਉਂਕਿ ਲਾਇਬ੍ਰੇਰੀ ਬਹੁਤ ਸਥਿਰ ਨਹੀਂ ਸੀ ਅਤੇ ਗਲਤ ਸਕਾਰਾਤਮਕ ਸਨ। ਸਕਰੀਨਸ਼ਾਟ ਟੈਸਟਾਂ ਨੂੰ ਜਾਂਚ ਸੂਚੀ ਵਿੱਚੋਂ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ.

ਨਤੀਜੇ ਵਜੋਂ, ਸਾਡੇ ਕੋਲ ਰਹਿ ਗਏ ਸਨ:

• ARK ਅਸੈਂਬਲੀ;
• ਜੂਨਿਟ ਟੈਸਟ;
• ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ ਟੈਸਟ।

ਗ੍ਰੇਡਲ ਰਿਮੋਟ ਕੈਸ਼

ਭਾਰੀ ਜਾਂਚਾਂ ਤੋਂ ਬਿਨਾਂ, ਸਭ ਕੁਝ ਬਿਹਤਰ ਹੋ ਗਿਆ. ਪਰ ਸੰਪੂਰਨਤਾ ਦੀ ਕੋਈ ਸੀਮਾ ਨਹੀਂ ਹੈ!

ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਲਗਭਗ 150 ਗ੍ਰੇਡਲ ਮੋਡੀਊਲਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਸੀ। Gradle ਰਿਮੋਟ ਕੈਸ਼ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਕੇਸ ਵਿੱਚ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਅਸੀਂ ਇਸਨੂੰ ਅਜ਼ਮਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।

ਗ੍ਰੇਡਲ ਰਿਮੋਟ ਕੈਸ਼ ਇੱਕ ਸੇਵਾ ਹੈ ਜੋ ਵਿਅਕਤੀਗਤ ਮੌਡਿਊਲਾਂ ਵਿੱਚ ਵਿਅਕਤੀਗਤ ਕੰਮਾਂ ਲਈ ਬਿਲਡ ਕਲਾਕ੍ਰਿਤੀਆਂ ਨੂੰ ਕੈਸ਼ ਕਰ ਸਕਦੀ ਹੈ। Gradle, ਅਸਲ ਵਿੱਚ ਕੋਡ ਨੂੰ ਕੰਪਾਇਲ ਕਰਨ ਦੀ ਬਜਾਏ, ਰਿਮੋਟ ਕੈਸ਼ ਨੂੰ ਖੜਕਾਉਣ ਲਈ HTTP ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਅਤੇ ਪੁੱਛਦਾ ਹੈ ਕਿ ਕੀ ਕਿਸੇ ਨੇ ਪਹਿਲਾਂ ਹੀ ਇਹ ਕੰਮ ਕੀਤਾ ਹੈ। ਜੇ ਹਾਂ, ਤਾਂ ਇਹ ਸਿਰਫ਼ ਨਤੀਜਾ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ।

Gradle ਰਿਮੋਟ ਕੈਸ਼ ਨੂੰ ਚਲਾਉਣਾ ਆਸਾਨ ਹੈ ਕਿਉਂਕਿ Gradle ਇੱਕ ਡੌਕਰ ਚਿੱਤਰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਇਹ ਤਿੰਨ ਘੰਟਿਆਂ ਵਿੱਚ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋ ਗਏ।

ਤੁਹਾਨੂੰ ਬੱਸ ਡੌਕਰ ਨੂੰ ਲਾਂਚ ਕਰਨਾ ਸੀ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਇੱਕ ਲਾਈਨ ਲਿਖਣੀ ਸੀ। ਪਰ ਹਾਲਾਂਕਿ ਇਸਨੂੰ ਜਲਦੀ ਲਾਂਚ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਹਰ ਚੀਜ਼ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨ ਲਈ ਇਸ ਨੂੰ ਕਾਫ਼ੀ ਸਮਾਂ ਲੱਗੇਗਾ।

ਹੇਠਾਂ ਕੈਸ਼ ਮਿਸ ਗ੍ਰਾਫ ਹੈ।

ਸ਼ੁਰੂ ਵਿੱਚ, ਕੈਸ਼ ਮਿਸ ਦੀ ਪ੍ਰਤੀਸ਼ਤਤਾ ਲਗਭਗ 65 ਸੀ। ਤਿੰਨ ਹਫ਼ਤਿਆਂ ਬਾਅਦ, ਅਸੀਂ ਇਸ ਮੁੱਲ ਨੂੰ 20% ਤੱਕ ਵਧਾਉਣ ਵਿੱਚ ਕਾਮਯਾਬ ਰਹੇ। ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਐਂਡਰੌਇਡ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਇਕੱਤਰ ਕੀਤੇ ਕਾਰਜਾਂ ਵਿੱਚ ਅਜੀਬ ਪਰਿਵਰਤਨਸ਼ੀਲ ਨਿਰਭਰਤਾਵਾਂ ਹਨ, ਜਿਸ ਕਾਰਨ ਗ੍ਰੇਡਲ ਕੈਸ਼ ਤੋਂ ਖੁੰਝ ਗਿਆ।

ਕੈਸ਼ ਨੂੰ ਜੋੜ ਕੇ, ਅਸੀਂ ਬਿਲਡ ਨੂੰ ਬਹੁਤ ਤੇਜ਼ ਕੀਤਾ ਹੈ। ਪਰ ਅਸੈਂਬਲੀ ਤੋਂ ਇਲਾਵਾ, ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ ਟੈਸਟ ਵੀ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਲੰਬਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ. ਸ਼ਾਇਦ ਹਰ ਪੁੱਲ ਬੇਨਤੀ ਲਈ ਸਾਰੇ ਟੈਸਟਾਂ ਨੂੰ ਚਲਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਹ ਪਤਾ ਲਗਾਉਣ ਲਈ, ਅਸੀਂ ਪ੍ਰਭਾਵ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

ਪ੍ਰਭਾਵ ਵਿਸ਼ਲੇਸ਼ਣ

ਪੁੱਲ ਬੇਨਤੀ 'ਤੇ, ਅਸੀਂ git diff ਨੂੰ ਇਕੱਠਾ ਕਰਦੇ ਹਾਂ ਅਤੇ ਸੋਧੇ Gradle ਮੋਡੀਊਲ ਲੱਭਦੇ ਹਾਂ।

ਇਹ ਸਿਰਫ਼ ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ ਟੈਸਟਾਂ ਨੂੰ ਚਲਾਉਣਾ ਸਮਝਦਾ ਹੈ ਜੋ ਬਦਲੇ ਹੋਏ ਮੋਡੀਊਲ ਅਤੇ ਉਹਨਾਂ 'ਤੇ ਨਿਰਭਰ ਸਾਰੇ ਮੋਡੀਊਲਾਂ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ। ਗੁਆਂਢੀ ਮੈਡਿਊਲਾਂ ਲਈ ਟੈਸਟ ਚਲਾਉਣ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ: ਉਥੇ ਕੋਡ ਨਹੀਂ ਬਦਲਿਆ ਹੈ ਅਤੇ ਕੁਝ ਵੀ ਨਹੀਂ ਟੁੱਟ ਸਕਦਾ ਹੈ।

ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ ਟੈਸਟ ਇੰਨੇ ਸਰਲ ਨਹੀਂ ਹਨ, ਕਿਉਂਕਿ ਉਹ ਉੱਚ-ਪੱਧਰੀ ਐਪਲੀਕੇਸ਼ਨ ਮੋਡੀਊਲ ਵਿੱਚ ਸਥਿਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਅਸੀਂ ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਹਰੇਕ ਟੈਸਟ ਕਿਸ ਮੋਡੀਊਲ ਨਾਲ ਸਬੰਧਤ ਹੈ, ਬਾਈਟਕੋਡ ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ ਨਾਲ ਹਿਊਰੀਸਟਿਕਸ ਦੀ ਵਰਤੋਂ ਕੀਤੀ।

ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ ਟੈਸਟਾਂ ਦੇ ਸੰਚਾਲਨ ਨੂੰ ਅਪਗ੍ਰੇਡ ਕਰਨਾ ਤਾਂ ਕਿ ਉਹ ਸਿਰਫ ਸ਼ਾਮਲ ਕੀਤੇ ਮੋਡਿਊਲਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਵਿੱਚ ਲਗਭਗ ਅੱਠ ਹਫ਼ਤੇ ਲੱਗ ਗਏ।

ਨਿਰੀਖਣਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਦੇ ਉਪਾਵਾਂ ਨੇ ਸਫਲਤਾਪੂਰਵਕ ਕੰਮ ਕੀਤਾ ਹੈ। 45 ਮਿੰਟਾਂ ਤੋਂ ਅਸੀਂ ਲਗਭਗ 15 ਤੱਕ ਚਲੇ ਗਏ। ਇੱਕ ਬਿਲਡ ਲਈ ਇੱਕ ਚੌਥਾਈ ਘੰਟੇ ਦਾ ਇੰਤਜ਼ਾਰ ਕਰਨਾ ਪਹਿਲਾਂ ਹੀ ਆਮ ਗੱਲ ਹੈ।

ਪਰ ਹੁਣ ਡਿਵੈਲਪਰਾਂ ਨੇ ਸ਼ਿਕਾਇਤ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ ਹੈ ਕਿ ਉਹ ਸਮਝ ਨਹੀਂ ਪਾਉਂਦੇ ਹਨ ਕਿ ਕਿਹੜੀ ਬਿਲਡ ਲਾਂਚ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ, ਲੌਗ ਕਿੱਥੇ ਦੇਖਣਾ ਹੈ, ਬਿਲਡ ਲਾਲ ਕਿਉਂ ਹੈ, ਕਿਹੜਾ ਟੈਸਟ ਫੇਲ ਹੋਇਆ ਹੈ, ਆਦਿ।

ਫੀਡਬੈਕ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਵਿਕਾਸ ਨੂੰ ਹੌਲੀ ਕਰਦੀਆਂ ਹਨ, ਇਸਲਈ ਅਸੀਂ ਹਰੇਕ PR ਬਾਰੇ ਸਪੱਸ਼ਟ ਅਤੇ ਵਿਸਤ੍ਰਿਤ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਅਤੇ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਨਿਰਮਾਣ ਕੀਤਾ। ਅਸੀਂ ਬਿੱਟਬਕੇਟ ਟੂ PR ਵਿੱਚ ਟਿੱਪਣੀਆਂ ਦੇ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕੀਤੀ, ਇਹ ਦਰਸਾਉਂਦੇ ਹੋਏ ਕਿ ਕਿਹੜੀ ਬਿਲਡ ਅਸਫਲ ਰਹੀ ਅਤੇ ਕਿਉਂ, ਅਤੇ ਸਲੈਕ ਵਿੱਚ ਨਿਸ਼ਾਨਾ ਸੰਦੇਸ਼ ਲਿਖੇ। ਅੰਤ ਵਿੱਚ, ਅਸੀਂ ਪੰਨੇ ਲਈ ਇੱਕ PR ਡੈਸ਼ਬੋਰਡ ਬਣਾਇਆ ਹੈ ਜਿਸ ਵਿੱਚ ਵਰਤਮਾਨ ਵਿੱਚ ਚੱਲ ਰਹੇ ਸਾਰੇ ਬਿਲਡਾਂ ਅਤੇ ਉਹਨਾਂ ਦੀ ਸਥਿਤੀ ਦੀ ਸੂਚੀ ਹੈ: ਕਤਾਰਬੱਧ, ਚੱਲ ਰਹੇ, ਕਰੈਸ਼ ਜਾਂ ਮੁਕੰਮਲ। ਤੁਸੀਂ ਬਿਲਡ 'ਤੇ ਕਲਿੱਕ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇਸਦੇ ਲੌਗ 'ਤੇ ਜਾ ਸਕਦੇ ਹੋ।

ਵਿਸਤ੍ਰਿਤ ਫੀਡਬੈਕ 'ਤੇ ਛੇ ਹਫ਼ਤੇ ਬਿਤਾਏ ਗਏ ਸਨ।

ਯੋਜਨਾਵਾਂ

ਚਲੋ ਤਾਜ਼ਾ ਇਤਿਹਾਸ ਵੱਲ ਵਧੀਏ। ਫੀਡਬੈਕ ਮੁੱਦੇ ਨੂੰ ਹੱਲ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਇੱਕ ਨਵੇਂ ਪੱਧਰ 'ਤੇ ਪਹੁੰਚ ਗਏ ਹਾਂ - ਅਸੀਂ ਆਪਣਾ ਖੁਦ ਦਾ ਈਮੂਲੇਟਰ ਫਾਰਮ ਬਣਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ। ਜਦੋਂ ਬਹੁਤ ਸਾਰੇ ਟੈਸਟ ਅਤੇ ਇਮੂਲੇਟਰ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਸਾਡੇ ਸਾਰੇ ਇਮੂਲੇਟਰ ਲਚਕਦਾਰ ਸਰੋਤ ਪ੍ਰਬੰਧਨ ਦੇ ਨਾਲ k8s ਕਲੱਸਟਰ ਵਿੱਚ ਚਲੇ ਗਏ।

ਇਸ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਵੀ ਯੋਜਨਾਵਾਂ ਹਨ।

• ਲਿੰਟ ਵਾਪਸ ਕਰੋ (ਅਤੇ ਹੋਰ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ)। ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਇਸ ਦਿਸ਼ਾ ਵਿੱਚ ਕੰਮ ਕਰ ਰਹੇ ਹਾਂ।
• ਇੱਕ PR ਬਲੌਕਰ 'ਤੇ ਸਭ ਕੁਝ ਚਲਾਓ ਅੰਤ-ਤੋਂ-ਅੰਤ ਟੈਸਟ ਸਾਰੇ SDK ਸੰਸਕਰਣਾਂ 'ਤੇ।

ਇਸ ਲਈ, ਅਸੀਂ ਅਵੀਟੋ ਵਿੱਚ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਦੇ ਵਿਕਾਸ ਦੇ ਇਤਿਹਾਸ ਦਾ ਪਤਾ ਲਗਾਇਆ ਹੈ. ਹੁਣ ਮੈਂ ਤਜਰਬੇਕਾਰ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਕੁਝ ਸਲਾਹ ਦੇਣਾ ਚਾਹੁੰਦਾ ਹਾਂ।

ਸੁਝਾਅ

ਜੇ ਮੈਂ ਸਿਰਫ਼ ਇੱਕ ਸਲਾਹ ਦੇ ਸਕਦਾ ਹਾਂ ਤਾਂ ਇਹ ਇਹ ਹੋਵੇਗਾ:

ਕਿਰਪਾ ਕਰਕੇ ਸ਼ੈੱਲ ਸਕ੍ਰਿਪਟਾਂ ਨਾਲ ਸਾਵਧਾਨ ਰਹੋ!

Bash ਇੱਕ ਬਹੁਤ ਹੀ ਲਚਕਦਾਰ ਅਤੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਟੂਲ ਹੈ, ਇਹ ਸਕ੍ਰਿਪਟਾਂ ਲਿਖਣ ਲਈ ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਅਤੇ ਤੇਜ਼ ਹੈ। ਪਰ ਤੁਸੀਂ ਇਸਦੇ ਨਾਲ ਇੱਕ ਜਾਲ ਵਿੱਚ ਫਸ ਸਕਦੇ ਹੋ, ਅਤੇ, ਬਦਕਿਸਮਤੀ ਨਾਲ, ਅਸੀਂ ਇਸ ਵਿੱਚ ਫਸ ਗਏ.

ਇਹ ਸਭ ਸਧਾਰਨ ਸਕ੍ਰਿਪਟਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੋਇਆ ਜੋ ਸਾਡੀਆਂ ਬਿਲਡ ਮਸ਼ੀਨਾਂ 'ਤੇ ਚੱਲਦੀਆਂ ਸਨ:

#!/usr/bin/env bash
./gradlew assembleDebug

ਪਰ, ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ, ਸਭ ਕੁਝ ਵਿਕਸਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਂਦਾ ਹੈ - ਚਲੋ ਇੱਕ ਸਕ੍ਰਿਪਟ ਨੂੰ ਦੂਜੀ ਤੋਂ ਚਲਾਉਂਦੇ ਹਾਂ, ਆਓ ਉੱਥੇ ਕੁਝ ਮਾਪਦੰਡਾਂ ਨੂੰ ਪਾਸ ਕਰੀਏ - ਅੰਤ ਵਿੱਚ ਸਾਨੂੰ ਇੱਕ ਫੰਕਸ਼ਨ ਲਿਖਣਾ ਪਿਆ ਜੋ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਅਸੀਂ ਹੁਣ ਕਿਸ ਪੱਧਰ 'ਤੇ ਬੈਸ਼ ਨੇਸਟਿੰਗ ਕ੍ਰਮ ਵਿੱਚ ਹਾਂ। ਇਹ ਸਭ ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਲੋੜੀਂਦੇ ਹਵਾਲੇ ਸ਼ਾਮਲ ਕਰਨ ਲਈ।

ਤੁਸੀਂ ਅਜਿਹੀਆਂ ਲਿਪੀਆਂ ਦੇ ਵਿਕਾਸ ਲਈ ਲੇਬਰ ਦੀ ਲਾਗਤ ਦੀ ਕਲਪਨਾ ਕਰ ਸਕਦੇ ਹੋ। ਮੈਂ ਤੁਹਾਨੂੰ ਇਸ ਜਾਲ ਵਿੱਚ ਨਾ ਫਸਣ ਦੀ ਸਲਾਹ ਦਿੰਦਾ ਹਾਂ।

ਕੀ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ?

• ਕੋਈ ਵੀ ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾ। ਨੂੰ ਲਿਖੋ ਪਾਈਥਨ ਜਾਂ ਕੋਟਲਿਨ ਸਕ੍ਰਿਪਟ ਵਧੇਰੇ ਸੁਵਿਧਾਜਨਕ ਕਿਉਂਕਿ ਇਹ ਪ੍ਰੋਗਰਾਮਿੰਗ ਹੈ, ਸਕ੍ਰਿਪਟਾਂ ਨਹੀਂ।
• ਜਾਂ ਫਾਰਮ ਵਿੱਚ ਸਾਰੇ ਬਿਲਡ ਤਰਕ ਦਾ ਵਰਣਨ ਕਰੋ ਕਸਟਮ ਗ੍ਰੇਡਲ ਕਾਰਜ ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਲਈ.

ਅਸੀਂ ਦੂਜਾ ਵਿਕਲਪ ਚੁਣਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ, ਅਤੇ ਹੁਣ ਅਸੀਂ ਯੋਜਨਾਬੱਧ ਢੰਗ ਨਾਲ ਸਾਰੀਆਂ ਬੈਸ਼ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਮਿਟਾ ਰਹੇ ਹਾਂ ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਕਸਟਮ ਗ੍ਰੇਡਲ ਕੰਮ ਲਿਖ ਰਹੇ ਹਾਂ।

ਸੰਕੇਤ #2: ਕੋਡ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਸਟੋਰ ਕਰੋ।

ਇਹ ਸੁਵਿਧਾਜਨਕ ਹੈ ਜਦੋਂ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਸੈਟਿੰਗ ਜੇਨਕਿੰਸ ਜਾਂ ਟੀਮਸਿਟੀ, ਆਦਿ ਦੇ UI ਇੰਟਰਫੇਸ ਵਿੱਚ ਨਹੀਂ, ਪਰ ਸਿੱਧੇ ਪ੍ਰੋਜੈਕਟ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਟੈਕਸਟ ਫਾਈਲਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਸੰਸਕਰਨਯੋਗਤਾ ਦਿੰਦਾ ਹੈ। ਕਿਸੇ ਹੋਰ ਸ਼ਾਖਾ 'ਤੇ ਕੋਡ ਨੂੰ ਰੋਲਬੈਕ ਕਰਨਾ ਜਾਂ ਬਣਾਉਣਾ ਮੁਸ਼ਕਲ ਨਹੀਂ ਹੋਵੇਗਾ।

ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਵਾਤਾਵਰਣ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ?

ਸੰਕੇਤ #3: ਡੌਕਰ ਵਾਤਾਵਰਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ।

ਇਹ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਐਂਡਰੌਇਡ ਡਿਵੈਲਪਰਾਂ ਦੀ ਮਦਦ ਕਰੇਗਾ; ਬਦਕਿਸਮਤੀ ਨਾਲ, iOS ਕੋਲ ਅਜੇ ਕੋਈ ਨਹੀਂ ਹੈ।

ਇਹ ਇੱਕ ਸਧਾਰਨ ਡੌਕਰ ਫਾਈਲ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਜਿਸ ਵਿੱਚ jdk ਅਤੇ android-sdk ਸ਼ਾਮਲ ਹਨ:

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

ਇਸ ਡੌਕਰ ਫਾਈਲ ਨੂੰ ਲਿਖਣ ਤੋਂ ਬਾਅਦ (ਮੈਂ ਤੁਹਾਨੂੰ ਇੱਕ ਰਾਜ਼ ਦੱਸਾਂਗਾ, ਤੁਹਾਨੂੰ ਇਸ ਨੂੰ ਲਿਖਣ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ, ਪਰ ਇਸਨੂੰ GitHub ਤੋਂ ਤਿਆਰ-ਬਣ ਕੇ ਖਿੱਚੋ) ਅਤੇ ਚਿੱਤਰ ਨੂੰ ਅਸੈਂਬਲ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਨੂੰ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਮਿਲਦੀ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾ ਸਕਦੇ ਹੋ। ਅਤੇ ਜੂਨਿਟ ਟੈਸਟ ਚਲਾਓ।

ਦੋ ਮੁੱਖ ਕਾਰਨ ਜਿਸ ਕਾਰਨ ਇਹ ਅਰਥ ਰੱਖਦਾ ਹੈ ਉਹ ਹਨ ਸਕੇਲੇਬਿਲਟੀ ਅਤੇ ਦੁਹਰਾਉਣਯੋਗਤਾ। ਡੌਕਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਤੁਸੀਂ ਇੱਕ ਦਰਜਨ ਬਿਲਡ ਏਜੰਟਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਉਭਾਰ ਸਕਦੇ ਹੋ ਜਿਨ੍ਹਾਂ ਦਾ ਪਿਛਲੇ ਇੱਕ ਵਰਗਾ ਵਾਤਾਵਰਣ ਹੋਵੇਗਾ। ਇਹ CI ਇੰਜੀਨੀਅਰਾਂ ਦੀ ਜ਼ਿੰਦਗੀ ਨੂੰ ਬਹੁਤ ਸੌਖਾ ਬਣਾਉਂਦਾ ਹੈ. ਐਂਡਰੌਇਡ-ਐਸਡੀਕੇ ਨੂੰ ਡੌਕਰ ਵਿੱਚ ਧੱਕਣਾ ਬਹੁਤ ਆਸਾਨ ਹੈ, ਪਰ ਇਮੂਲੇਟਰਾਂ ਨਾਲ ਇਹ ਥੋੜਾ ਹੋਰ ਮੁਸ਼ਕਲ ਹੈ: ਤੁਹਾਨੂੰ ਥੋੜਾ ਹੋਰ ਮਿਹਨਤ ਕਰਨੀ ਪਵੇਗੀ (ਜਾਂ ਗਿੱਟਹੱਬ ਤੋਂ ਦੁਬਾਰਾ ਡਾਊਨਲੋਡ ਕਰੋ)।

ਨੁਕਤਾ ਨੰਬਰ 4: ਇਹ ਨਾ ਭੁੱਲੋ ਕਿ ਨਿਰੀਖਣ ਨਿਰੀਖਣ ਲਈ ਨਹੀਂ, ਲੋਕਾਂ ਲਈ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

ਤੇਜ਼ ਅਤੇ, ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਸਪਸ਼ਟ ਫੀਡਬੈਕ ਡਿਵੈਲਪਰਾਂ ਲਈ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਕੀ ਟੁੱਟਿਆ, ਕਿਹੜਾ ਟੈਸਟ ਅਸਫਲ ਹੋਇਆ, ਮੈਂ ਬਿਲਡਲੌਗ ਕਿੱਥੇ ਦੇਖ ਸਕਦਾ ਹਾਂ.

ਟਿਪ #5: ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਨੂੰ ਵਿਕਸਿਤ ਕਰਦੇ ਸਮੇਂ ਵਿਹਾਰਕ ਬਣੋ।

ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਸਮਝੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਰੋਕਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤੁਸੀਂ ਕਿੰਨੇ ਸਰੋਤ, ਸਮਾਂ ਅਤੇ ਕੰਪਿਊਟਰ ਸਮਾਂ ਖਰਚਣ ਲਈ ਤਿਆਰ ਹੋ। ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੈਣ ਵਾਲੀਆਂ ਜਾਂਚਾਂ, ਉਦਾਹਰਨ ਲਈ, ਰਾਤੋ-ਰਾਤ ਮੁਲਤਵੀ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਜਿਹੜੇ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਗਲਤੀਆਂ ਨਹੀਂ ਫੜਦੇ ਹਨ ਉਹਨਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ.

ਟਿਪ #6: ਤਿਆਰ ਕੀਤੇ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰੋ।

ਹੁਣ ਬਹੁਤ ਸਾਰੀਆਂ ਕੰਪਨੀਆਂ ਹਨ ਜੋ ਕਲਾਉਡ ਸੀਆਈ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ।

ਇਹ ਛੋਟੀਆਂ ਟੀਮਾਂ ਲਈ ਇੱਕ ਵਧੀਆ ਹੱਲ ਹੈ। ਤੁਹਾਨੂੰ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਦਾ ਸਮਰਥਨ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਸਿਰਫ਼ ਥੋੜੇ ਜਿਹੇ ਪੈਸੇ ਦਾ ਭੁਗਤਾਨ ਕਰੋ, ਆਪਣੀ ਅਰਜ਼ੀ ਬਣਾਓ ਅਤੇ ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ ਟੈਸਟ ਵੀ ਚਲਾਓ।

ਸੰਕੇਤ #7: ਇੱਕ ਵੱਡੀ ਟੀਮ ਵਿੱਚ, ਅੰਦਰੂਨੀ ਹੱਲ ਵਧੇਰੇ ਲਾਭਕਾਰੀ ਹੁੰਦੇ ਹਨ।

ਪਰ ਜਲਦੀ ਜਾਂ ਬਾਅਦ ਵਿੱਚ, ਜਿਵੇਂ ਕਿ ਟੀਮ ਵਧਦੀ ਹੈ, ਅੰਦਰੂਨੀ ਹੱਲ ਵਧੇਰੇ ਲਾਭਦਾਇਕ ਬਣ ਜਾਣਗੇ। ਇਹਨਾਂ ਫੈਸਲਿਆਂ ਵਿੱਚ ਇੱਕ ਸਮੱਸਿਆ ਹੈ। ਅਰਥ ਸ਼ਾਸਤਰ ਵਿੱਚ ਰਿਟਰਨ ਘਟਾਉਣ ਦਾ ਇੱਕ ਕਾਨੂੰਨ ਹੈ: ਕਿਸੇ ਵੀ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ, ਹਰੇਕ ਬਾਅਦ ਵਿੱਚ ਸੁਧਾਰ ਵਧੇਰੇ ਅਤੇ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਵੱਧ ਤੋਂ ਵੱਧ ਨਿਵੇਸ਼ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਅਰਥ ਸ਼ਾਸਤਰ ਸਾਡੇ ਪੂਰੇ ਜੀਵਨ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਸ਼ਾਮਲ ਹੈ। ਮੈਂ ਸਾਡੇ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਦੇ ਵਿਕਾਸ ਦੇ ਹਰੇਕ ਪੜਾਅ ਲਈ ਕਿਰਤ ਲਾਗਤਾਂ ਦਾ ਇੱਕ ਅਨੁਸੂਚੀ ਬਣਾਇਆ ਹੈ।

ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਕੋਈ ਵੀ ਸੁਧਾਰ ਹੋਰ ਅਤੇ ਹੋਰ ਜਿਆਦਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਜਾ ਰਿਹਾ ਹੈ. ਇਸ ਗ੍ਰਾਫ ਨੂੰ ਦੇਖਦੇ ਹੋਏ, ਤੁਸੀਂ ਸਮਝ ਸਕਦੇ ਹੋ ਕਿ ਟੀਮ ਦੇ ਆਕਾਰ ਦੇ ਵਾਧੇ ਦੇ ਅਨੁਸਾਰ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਦੋ ਲੋਕਾਂ ਦੀ ਇੱਕ ਟੀਮ ਲਈ, ਅੰਦਰੂਨੀ ਇਮੂਲੇਟਰ ਫਾਰਮ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਵਿੱਚ 50 ਦਿਨ ਬਿਤਾਉਣਾ ਇੱਕ ਮੱਧਮ ਵਿਚਾਰ ਹੈ। ਪਰ ਉਸੇ ਸਮੇਂ, ਇੱਕ ਵੱਡੀ ਟੀਮ ਲਈ, ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਬਿਲਕੁਲ ਨਾ ਕਰਨਾ ਵੀ ਇੱਕ ਮਾੜਾ ਵਿਚਾਰ ਹੈ, ਕਿਉਂਕਿ ਏਕੀਕਰਣ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ, ਸੰਚਾਰ ਨੂੰ ਠੀਕ ਕਰਨਾ, ਆਦਿ। ਇਸ ਨੂੰ ਹੋਰ ਵੀ ਸਮਾਂ ਲੱਗੇਗਾ।

ਅਸੀਂ ਇਸ ਵਿਚਾਰ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕੀਤੀ ਕਿ ਆਟੋਮੇਸ਼ਨ ਦੀ ਲੋੜ ਹੈ ਕਿਉਂਕਿ ਲੋਕ ਮਹਿੰਗੇ ਹਨ, ਉਹ ਗਲਤੀਆਂ ਕਰਦੇ ਹਨ ਅਤੇ ਆਲਸੀ ਹਨ। ਪਰ ਲੋਕ ਵੀ ਆਟੋਮੈਟਿਕ. ਇਸ ਲਈ, ਸਾਰੀਆਂ ਇੱਕੋ ਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਆਟੋਮੇਸ਼ਨ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ.

• ਆਟੋਮੇਸ਼ਨ ਮਹਿੰਗਾ ਹੈ. ਲੇਬਰ ਅਨੁਸੂਚੀ ਨੂੰ ਯਾਦ ਰੱਖੋ.
• ਜਦੋਂ ਆਟੋਮੇਸ਼ਨ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ, ਲੋਕ ਗਲਤੀਆਂ ਕਰਦੇ ਹਨ।
• ਕਦੇ-ਕਦੇ ਇਹ ਸਵੈਚਲਿਤ ਕਰਨ ਲਈ ਬਹੁਤ ਆਲਸੀ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਭ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਨੂੰ ਕਿਉਂ ਸੁਧਾਰੀਏ, ਇਹ ਸਭ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਕਿਉਂ?

ਪਰ ਮੇਰੇ ਕੋਲ ਅੰਕੜੇ ਹਨ: 20% ਅਸੈਂਬਲੀਆਂ ਵਿੱਚ ਗਲਤੀਆਂ ਫੜੀਆਂ ਗਈਆਂ ਹਨ। ਅਤੇ ਇਹ ਇਸ ਲਈ ਨਹੀਂ ਹੈ ਕਿਉਂਕਿ ਸਾਡੇ ਡਿਵੈਲਪਰ ਮਾੜੇ ਢੰਗ ਨਾਲ ਕੋਡ ਲਿਖਦੇ ਹਨ. ਇਹ ਇਸ ਲਈ ਹੈ ਕਿਉਂਕਿ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਭਰੋਸਾ ਹੈ ਕਿ ਜੇਕਰ ਉਹ ਕੁਝ ਗਲਤੀ ਕਰਦੇ ਹਨ, ਤਾਂ ਇਹ ਵਿਕਾਸ ਵਿੱਚ ਖਤਮ ਨਹੀਂ ਹੋਵੇਗਾ, ਇਹ ਸਵੈਚਲਿਤ ਜਾਂਚਾਂ ਦੁਆਰਾ ਫੜਿਆ ਜਾਵੇਗਾ। ਇਸ ਅਨੁਸਾਰ, ਡਿਵੈਲਪਰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਚਲਾਉਣ ਅਤੇ ਟੈਸਟ ਕਰਨ ਦੀ ਬਜਾਏ ਕੋਡ ਅਤੇ ਦਿਲਚਸਪ ਚੀਜ਼ਾਂ ਲਿਖਣ ਵਿੱਚ ਵਧੇਰੇ ਸਮਾਂ ਬਿਤਾ ਸਕਦੇ ਹਨ।

ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਦਾ ਅਭਿਆਸ ਕਰੋ। ਪਰ ਸੰਜਮ ਵਿੱਚ.

ਵੈਸੇ, ਨਿਕੋਲਾਈ ਨੇਸਟਰੋਵ ਨਾ ਸਿਰਫ ਖੁਦ ਵਧੀਆ ਰਿਪੋਰਟਾਂ ਦਿੰਦਾ ਹੈ, ਬਲਕਿ ਪ੍ਰੋਗਰਾਮ ਕਮੇਟੀ ਦਾ ਮੈਂਬਰ ਵੀ ਹੈ | AppsConf ਅਤੇ ਦੂਜਿਆਂ ਨੂੰ ਤੁਹਾਡੇ ਲਈ ਅਰਥਪੂਰਨ ਭਾਸ਼ਣ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਅਗਲੇ ਕਾਨਫਰੰਸ ਪ੍ਰੋਗਰਾਮ ਦੀ ਸੰਪੂਰਨਤਾ ਅਤੇ ਉਪਯੋਗਤਾ ਦਾ ਮੁਲਾਂਕਣ ਵਿਸ਼ਿਆਂ ਦੁਆਰਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਸਮਾਸੂਚੀ, ਕਾਰਜ - ਕ੍ਰਮ. ਅਤੇ ਵੇਰਵਿਆਂ ਲਈ, 22-23 ਅਪ੍ਰੈਲ ਨੂੰ ਇਨਫੋਸਪੇਸ 'ਤੇ ਆਓ।

ਸਰੋਤ: www.habr.com