DevOps - VTB ਅਨੁਭਵ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਪੂਰਨ ਅੰਦਰੂਨੀ ਵਿਕਾਸ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ

DevOps ਅਭਿਆਸ ਕੰਮ ਕਰਦੇ ਹਨ। ਜਦੋਂ ਅਸੀਂ ਰੀਲੀਜ਼ ਇੰਸਟਾਲੇਸ਼ਨ ਦੇ ਸਮੇਂ ਨੂੰ 10 ਗੁਣਾ ਘਟਾ ਦਿੱਤਾ ਤਾਂ ਸਾਨੂੰ ਖੁਦ ਇਸ ਬਾਰੇ ਯਕੀਨ ਹੋ ਗਿਆ ਸੀ। FIS ਪ੍ਰੋਫਾਈਲ ਸਿਸਟਮ ਵਿੱਚ, ਜੋ ਅਸੀਂ VTB 'ਤੇ ਵਰਤਦੇ ਹਾਂ, ਇੰਸਟਾਲੇਸ਼ਨ ਵਿੱਚ ਹੁਣ 90 ਦੀ ਬਜਾਏ 10 ਮਿੰਟ ਲੱਗਦੇ ਹਨ। ਰਿਲੀਜ਼ ਬਿਲਡ ਟਾਈਮ ਦੋ ਹਫ਼ਤਿਆਂ ਤੋਂ ਘਟ ਕੇ ਦੋ ਦਿਨ ਹੋ ਗਿਆ ਹੈ। ਸਥਾਈ ਲਾਗੂ ਕਰਨ ਦੇ ਨੁਕਸ ਦੀ ਗਿਣਤੀ ਲਗਭਗ ਇੱਕ ਘੱਟੋ ਘੱਟ ਹੋ ਗਈ ਹੈ. "ਹੱਥੀ ਕਿਰਤ" ਤੋਂ ਦੂਰ ਹੋਣ ਅਤੇ ਵਿਕਰੇਤਾ 'ਤੇ ਨਿਰਭਰਤਾ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਬੈਸਾਖੀਆਂ ਨਾਲ ਕੰਮ ਕਰਨਾ ਪਿਆ ਅਤੇ ਅਚਾਨਕ ਹੱਲ ਲੱਭਣੇ ਪਏ। ਕੱਟ ਦੇ ਹੇਠਾਂ ਇੱਕ ਵਿਸਤ੍ਰਿਤ ਕਹਾਣੀ ਹੈ ਕਿ ਅਸੀਂ ਇੱਕ ਪੂਰਨ ਅੰਦਰੂਨੀ ਵਿਕਾਸ ਕਿਵੇਂ ਬਣਾਇਆ।

 

ਪ੍ਰੋਲੋਗ: DevOps ਇੱਕ ਦਰਸ਼ਨ ਹੈ

ਪਿਛਲੇ ਸਾਲ ਦੌਰਾਨ, ਅਸੀਂ VTB 'ਤੇ DevOps ਅਭਿਆਸਾਂ ਦੇ ਅੰਦਰੂਨੀ ਵਿਕਾਸ ਅਤੇ ਲਾਗੂ ਕਰਨ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਲਈ ਬਹੁਤ ਸਾਰਾ ਕੰਮ ਕੀਤਾ ਹੈ:

• ਅਸੀਂ 12 ਪ੍ਰਣਾਲੀਆਂ ਲਈ ਅੰਦਰੂਨੀ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆਵਾਂ ਬਣਾਈਆਂ;
• ਅਸੀਂ 15 ਪਾਈਪਲਾਈਨਾਂ ਲਾਂਚ ਕੀਤੀਆਂ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਚਾਰ ਉਤਪਾਦਨ ਲਈ ਲਿਆਂਦੀਆਂ ਗਈਆਂ;
• ਸਵੈਚਲਿਤ 1445 ਟੈਸਟ ਦ੍ਰਿਸ਼;
• ਅਸੀਂ ਇਨ-ਹਾਊਸ ਟੀਮਾਂ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੀਆਂ ਕਈ ਰੀਲੀਜ਼ਾਂ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਲਾਗੂ ਕੀਤਾ ਹੈ।

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

ਪਹਿਲਾਂ, ਲਾਗੂ ਕਰਨ ਦਾ ਐਲਗੋਰਿਦਮ ਸਧਾਰਨ ਅਤੇ ਸਪਸ਼ਟ ਜਾਪਦਾ ਸੀ:

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

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

ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਇਹ ਲੋੜੀਂਦੇ ਨਤੀਜੇ ਲਈ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਊਰਜਾ-ਕੁਸ਼ਲ ਮਾਰਗ ਹੈ: ਇੱਥੇ DevOps ਹੈ, ਇੱਥੇ ਟੀਮ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਮੈਟ੍ਰਿਕਸ ਹਨ, ਇੱਥੇ ਇਕੱਤਰ ਕੀਤੀ ਮੁਹਾਰਤ ਹੈ... ਪਰ ਅਭਿਆਸ ਵਿੱਚ, ਸਾਨੂੰ ਇੱਕ ਹੋਰ ਪੁਸ਼ਟੀ ਮਿਲੀ ਹੈ ਕਿ DevOps ਅਜੇ ਵੀ ਫ਼ਲਸਫ਼ੇ ਬਾਰੇ ਹੈ , ਅਤੇ "ਗਿਟਲੈਬ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਜੁੜਿਆ ਨਹੀਂ, ਜਵਾਬਦੇਹ, ਗਠਜੋੜ ਅਤੇ ਸੂਚੀ ਵਿੱਚ ਅੱਗੇ।"

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

ਅੰਦਰੂਨੀ ਵਿਕਾਸ ਕਿੱਥੇ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ? 

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

• ਵਿਦੇਸ਼ੀ ਭਾਸ਼ਾ (MUMPS);
• ਕੰਸੋਲ ਇੰਟਰਫੇਸ;
• ਪ੍ਰਸਿੱਧ ਆਟੋਮੇਸ਼ਨ ਟੂਲਸ ਅਤੇ ਫਰੇਮਵਰਕ ਦੇ ਨਾਲ ਏਕੀਕਰਣ ਦੀ ਘਾਟ;
• ਟੈਰਾਬਾਈਟ ਦੇ ਦਸਾਂ ਵਿੱਚ ਡਾਟਾ ਵਾਲੀਅਮ;
• ਪ੍ਰਤੀ ਘੰਟਾ 2 ਮਿਲੀਅਨ ਤੋਂ ਵੱਧ ਓਪਰੇਸ਼ਨਾਂ ਦਾ ਲੋਡ;
• ਮਹੱਤਵ - ਵਪਾਰ - ਨਾਜ਼ੁਕ.

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

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

ਅਸੀਂ ਮੁਹਾਰਤ ਵਿਕਸਿਤ ਕਰਨ ਅਤੇ ਸਿਸਟਮ ਵਿੱਚ ਆਪਣੇ ਆਪ ਨੂੰ ਲੀਨ ਕਰਨ ਵਿੱਚ ਤਿੰਨ ਮਹੀਨੇ ਬਿਤਾਏ, ਅਤੇ 2019 ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ, ਅੰਦਰੂਨੀ ਵਿਕਾਸ ਨੇ ਇੱਕ ਚਮਕਦਾਰ ਭਵਿੱਖ ਵੱਲ ਆਪਣੀ ਗਤੀ ਸ਼ੁਰੂ ਕੀਤੀ, ਕਈ ਵਾਰ ਮੁਸ਼ਕਲ ਨਾਲ, ਪਰ ਭਰੋਸੇ ਨਾਲ ਅਤੇ ਉਦੇਸ਼ ਨਾਲ।

ਰਿਪੋਜ਼ਟਰੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਅਤੇ ਆਟੋਟੈਸਟ

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

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

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

ਇਹ ਕਿਵੇਂ ਸੀ: ਆਟੋਮੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਮਾਡਲ

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

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

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

ਕੋਡ ਦਾ ਲੋੜੀਂਦਾ ਸੰਸਕਰਣ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਇੰਸਟਾਲੇਸ਼ਨ ਆਰਡਰ ਦੀ ਸਖਤੀ ਨਾਲ ਪਾਲਣਾ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ, ਜਿਸ ਦੌਰਾਨ ਵਸਤੂਆਂ ਨੂੰ ਕਈ ਵਾਰ ਭੌਤਿਕ ਤੌਰ 'ਤੇ ਦੁਬਾਰਾ ਲਿਖਿਆ ਗਿਆ ਸੀ, ਕੁਝ 10-12 ਵਾਰ।

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

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

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

ਪਹਿਲੇ ਅੱਪਡੇਟ: ਅਸੈਂਬਲੀ ਅਤੇ ਸਪੁਰਦਗੀ

ਇਸ ਰੂਟ ਦੇ ਨਾਲ ਇੱਕ ਪਾਈਪ ਦੁਆਰਾ ਕੋਡ ਪ੍ਰਸਾਰਿਤ ਕਰਕੇ ਸਵੈਚਾਲਨ ਸ਼ੁਰੂ ਹੋਇਆ:

• ਸਟੋਰੇਜ ਤੋਂ ਮੁਕੰਮਲ ਡਿਲੀਵਰੀ ਚੁੱਕੋ;
• ਇਸ ਨੂੰ ਸਮਰਪਿਤ ਵਾਤਾਵਰਣ 'ਤੇ ਸਥਾਪਿਤ ਕਰੋ;
• ਆਟੋਟੈਸਟ ਚਲਾਓ;
• ਇੰਸਟਾਲੇਸ਼ਨ ਨਤੀਜੇ ਦਾ ਮੁਲਾਂਕਣ ਕਰੋ;
• ਟੈਸਟਿੰਗ ਕਮਾਂਡ ਦੇ ਪਾਸੇ ਹੇਠ ਦਿੱਤੀ ਪਾਈਪਲਾਈਨ ਨੂੰ ਕਾਲ ਕਰੋ।

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

• ਹਰੇਕ ਸੋਧ ਇੱਕ ਵੱਖਰੀ ਸ਼ਾਖਾ ਵਿੱਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਕਿ ਇੰਸਟਾਲੇਸ਼ਨ ਪੈਕੇਜ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ ਅਤੇ ਟਾਰਗੇਟ ਮਾਸਟਰ ਸ਼ਾਖਾ ਵਿੱਚ ਅਭੇਦ ਹੋ ਜਾਂਦੀ ਹੈ;
• ਪਾਈਪਲਾਈਨ ਲਾਂਚ ਟ੍ਰਿਗਰ ਇੱਕ ਅਭੇਦ ਬੇਨਤੀ ਦੁਆਰਾ ਮਾਸਟਰ ਬ੍ਰਾਂਚ ਵਿੱਚ ਇੱਕ ਨਵੀਂ ਪ੍ਰਤੀਬੱਧਤਾ ਦੀ ਦਿੱਖ ਹੈ, ਜੋ ਕਿ ਇਨਹਾਊਸ ਟੀਮ ਦੇ ਮੇਨਟੇਨਰਾਂ ਦੁਆਰਾ ਬੰਦ ਕੀਤਾ ਗਿਆ ਹੈ;
• ਰਿਪੋਜ਼ਟਰੀਆਂ ਨੂੰ ਹਰ ਪੰਜ ਮਿੰਟਾਂ ਵਿੱਚ ਇੱਕ ਵਾਰ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ;
• ਇੰਸਟਾਲੇਸ਼ਨ ਪੈਕੇਜ ਦੀ ਅਸੈਂਬਲੀ ਸ਼ੁਰੂ ਕੀਤੀ ਗਈ ਹੈ - ਵਿਕਰੇਤਾ ਤੋਂ ਪ੍ਰਾਪਤ ਅਸੈਂਬਲਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ।

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

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

ਅੰਤਮ ਹੱਲ: ਸੰਚਤ ਇੰਸਟਾਲੇਸ਼ਨ ਪੈਕੇਜ 

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

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

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

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

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

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

ਪਹਿਲੀ ਵਾਰ, ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਗਲਤੀਆਂ ਤੋਂ ਬਿਨਾਂ

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

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

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

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

ਨਤੀਜੇ ਅਤੇ ਸਿੱਟੇ

ਇੱਕ ਸਾਲ ਤੋਂ ਵੀ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਅਸੀਂ ਇਹ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋਏ:

• ਇੱਕ ਵਿਦੇਸ਼ੀ ਪ੍ਰਣਾਲੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਪੂਰਨ ਅੰਦਰੂਨੀ ਵਿਕਾਸ ਦਾ ਨਿਰਮਾਣ ਕਰੋ;
• ਨਾਜ਼ੁਕ ਵਿਕਰੇਤਾ ਨਿਰਭਰਤਾ ਨੂੰ ਖਤਮ ਕਰੋ;
• ਇੱਕ ਬਹੁਤ ਹੀ ਦੋਸਤਾਨਾ ਵਿਰਾਸਤ ਲਈ CI/CD ਲਾਂਚ ਕਰੋ;
• ਇੱਕ ਨਵੇਂ ਤਕਨੀਕੀ ਪੱਧਰ ਤੱਕ ਲਾਗੂ ਕਰਨ ਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਵਧਾਓ;
• ਤੈਨਾਤੀ ਦੇ ਸਮੇਂ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਘਟਾਓ;
• ਲਾਗੂ ਕਰਨ ਦੀਆਂ ਗਲਤੀਆਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਘਟਾਓ;
• ਭਰੋਸੇ ਨਾਲ ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਪ੍ਰਮੁੱਖ ਵਿਕਾਸ ਮਾਹਰ ਵਜੋਂ ਘੋਸ਼ਿਤ ਕਰੋ।

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

ਸਰੋਤ: www.habr.com