ਅਸੀਂ GitLab ਵਿੱਚ ਸੌਫਟਵੇਅਰ ਪੈਚ ਕਿਵੇਂ ਜਾਰੀ ਕਰਦੇ ਹਾਂ

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

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

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

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

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

ਡਿਲਿਵਰੀ ਟੀਮ ਘੱਟ ਕਰਨ ਲਈ ਰੀਲੀਜ਼ ਬਣਾਉਣ ਵਿੱਚ ਸ਼ਾਮਲ ਜ਼ਿਆਦਾਤਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਨ ਲਈ ਸਖ਼ਤ ਮਿਹਨਤ ਕਰ ਰਹੀ ਹੈ MTTP (ਉਤਪਾਦਨ ਦਾ ਸਮਾਂ, ਭਾਵ ਉਤਪਾਦਨ 'ਤੇ ਬਿਤਾਇਆ ਗਿਆ ਸਮਾਂ), ਡਿਵੈਲਪਰ ਦੁਆਰਾ gitlab.com 'ਤੇ ਤੈਨਾਤੀ ਕਰਨ ਲਈ ਇੱਕ ਵਿਲੀਨ ਬੇਨਤੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਤੋਂ ਲੈ ਕੇ ਸਮੇਂ ਦੀ ਮਿਆਦ।

«ਡਿਲਿਵਰੀ ਟੀਮ ਦਾ ਟੀਚਾ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਅਸੀਂ ਇੱਕ ਕੰਪਨੀ ਦੇ ਤੌਰ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧ ਸਕੀਏ, ਜਾਂ ਘੱਟੋ-ਘੱਟ ਡਿਲਿਵਰੀ ਲੋਕਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰ ਸਕੀਏ, ਸਹੀ।?, ਮਾਰਿਨ ਕਹਿੰਦਾ ਹੈ।

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

ਰੀਲੀਜ਼ ਮੈਨੇਜਰ ਕੀ ਕਰਦਾ ਹੈ?

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

ਸਵੈ-ਇੰਸਟਾਲੇਸ਼ਨ ਰੀਲੀਜ਼ ਅਤੇ gitlab.com ਰੀਲੀਜ਼ ਸਮਾਨ ਵਰਕਫਲੋ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਪਰ ਵੱਖ-ਵੱਖ ਸਮਿਆਂ 'ਤੇ ਚੱਲਦੇ ਹਨ, ਮਾਰਿਨ ਦੱਸਦੀ ਹੈ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਰੀਲੀਜ਼ ਮੈਨੇਜਰ, ਰੀਲੀਜ਼ ਦੀ ਕਿਸਮ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ, ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰਦਾ ਹੈ ਕਿ gitlab.com 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਲਾਂਚ ਹੋਣ ਤੋਂ ਬਾਅਦ GitLab ਉਪਲਬਧ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੈ, ਜਿਸ ਵਿੱਚ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਵੀ ਸ਼ਾਮਲ ਹੈ ਕਿ ਉਹੀ ਮੁੱਦੇ ਗਾਹਕਾਂ ਦੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਖਤਮ ਨਹੀਂ ਹੁੰਦੇ ਹਨ. ਆਪਣੀ ਸਮਰੱਥਾ.

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

ਰੀਲੀਜ਼ ਮੈਨੇਜਰ ਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਇੱਕ ਫਿਕਸ ਤਿਆਰ ਕਰਨਾ ਹੈ, ਜਾਂ ਇਸਨੂੰ ਕਦੋਂ ਲਾਗੂ ਕਰਨਾ ਹੈ - ਅਤੇ ਇਹ ਸਥਿਤੀ ਦੇ ਸੰਦਰਭ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, "ਇਸ ਦੌਰਾਨ, ਮਸ਼ੀਨਾਂ ਲੋਕਾਂ ਵਾਂਗ ਸੰਦਰਭ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਵਿੱਚ ਉੱਨੀਆਂ ਚੰਗੀਆਂ ਨਹੀਂ ਹਨ"ਮਾਰਿਨ ਕਹਿੰਦਾ ਹੈ.

ਇਹ ਸਭ ਫਿਕਸ ਬਾਰੇ ਹੈ

ਪੈਚ ਕੀ ਹਨ ਅਤੇ ਸਾਨੂੰ ਉਹਨਾਂ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?

ਰੀਲੀਜ਼ ਮੈਨੇਜਰ ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਬੱਗ ਦੀ ਗੰਭੀਰਤਾ ਦੇ ਅਧਾਰ ਤੇ ਇੱਕ ਫਿਕਸ ਜਾਰੀ ਕਰਨਾ ਹੈ ਜਾਂ ਨਹੀਂ।

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

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

ਇੱਕ ਵਾਰ ਕਮਜ਼ੋਰੀਆਂ S1 ਜਾਂ S2 ਲਈ ਇੱਕ ਪੈਚ ਤਿਆਰ ਹੋ ਜਾਣ 'ਤੇ, ਰੀਲੀਜ਼ ਮੈਨੇਜਰ ਪੈਚ ਨੂੰ ਜਾਰੀ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ।

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

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

ਰੀਲੀਜ਼ ਮੈਨੇਜਰ ਪੈਚ ਕਿਵੇਂ ਬਣਾਉਂਦਾ ਹੈ

ਅਸੀਂ ਪੈਚ ਬਣਾਉਣ ਲਈ GitLab CI ਅਤੇ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜਿਵੇਂ ਸਾਡੇ ChatOps ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਰੀਲੀਜ਼ ਮੈਨੇਜਰ ਸਾਡੇ ਅੰਦਰੂਨੀ ਚੈਨਲ 'ਤੇ ChatOps ਟੀਮ ਨੂੰ ਸਰਗਰਮ ਕਰਕੇ ਫਿਕਸ ਦੀ ਰਿਲੀਜ਼ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ #releases ਸਲੈਕ ਵਿੱਚ.

/chatops run release prepare 12.10.1

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

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

ਹੇਠਾਂ ਦਿੱਤੀ ਵੀਡੀਓ ਗਿਟਲੈਬ ਲਈ ਪੈਚ ਤਿਆਰ ਕਰਨ ਦੀ ਤਕਨੀਕੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ।

gitlab.com 'ਤੇ ਆਟੋਮੈਟਿਕ ਤੈਨਾਤੀ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ

gitlab.com ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਵਰਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਟੂਲ ਪੈਚ ਬਣਾਉਣ ਲਈ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਸਮਾਨ ਹਨ। gitlab.com ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਰੀਲੀਜ਼ ਮੈਨੇਜਰ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਘੱਟ ਦਸਤੀ ਕੰਮ ਦੀ ਲੋੜ ਹੈ।

ChatOps ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਤੈਨਾਤੀਆਂ ਨੂੰ ਚਲਾਉਣ ਦੀ ਬਜਾਏ, ਅਸੀਂ CI ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ ਜਿਵੇਂ ਕਿ ਨਿਯਤ ਪਾਈਪਲਾਈਨ, ਜਿਸ ਨਾਲ ਰੀਲੀਜ਼ ਮੈਨੇਜਰ ਲੋੜੀਂਦੇ ਸਮੇਂ 'ਤੇ ਕੀਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਕੁਝ ਕਾਰਵਾਈਆਂ ਨੂੰ ਤਹਿ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਮੈਨੂਅਲ ਪ੍ਰਕਿਰਿਆ ਦੀ ਬਜਾਏ, ਇੱਕ ਪਾਈਪਲਾਈਨ ਹੈ ਜੋ ਇੱਕ ਘੰਟੇ ਵਿੱਚ ਇੱਕ ਵਾਰ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਚੱਲਦੀ ਹੈ ਜੋ GitLab ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਕੀਤੀਆਂ ਗਈਆਂ ਨਵੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਦੀ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਪੈਕੇਜ ਕਰਦੀ ਹੈ ਅਤੇ ਤੈਨਾਤੀ ਨੂੰ ਅਨੁਸੂਚਿਤ ਕਰਦੀ ਹੈ, ਅਤੇ ਆਪਣੇ ਆਪ ਟੈਸਟਿੰਗ, QA ਅਤੇ ਹੋਰ ਲੋੜੀਂਦੇ ਕਦਮਾਂ ਨੂੰ ਚਲਾਉਂਦੀ ਹੈ।

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

gitlab.com ਅੱਪਡੇਟ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ CICD ਤਕਨਾਲੋਜੀ ਪੂਰੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਉਸ ਬਿੰਦੂ ਤੱਕ ਸਵੈਚਾਲਤ ਕਰਦੀ ਹੈ ਜਿੱਥੇ ਰੀਲੀਜ਼ ਮੈਨੇਜਰ ਨੂੰ gitlab.com 'ਤੇ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ ਦੀ ਤੈਨਾਤੀ ਨੂੰ ਦਸਤੀ ਲਾਂਚ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਮਾਰਿਨ ਹੇਠਾਂ ਦਿੱਤੀ ਵੀਡੀਓ ਵਿੱਚ gitlab.com ਅਪਡੇਟ ਪ੍ਰਕਿਰਿਆ ਬਾਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਜਾਂਦੀ ਹੈ।

ਡਿਲਿਵਰੀ ਟੀਮ ਹੋਰ ਕੀ ਕਰਦੀ ਹੈ?

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

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

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

ਡਿਲੀਵਰੀ ਟੀਮ gitlab.com ਨੂੰ ਕੁਬਰਨੇਟਸ-ਅਧਾਰਿਤ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਮਾਈਗਰੇਟ ਕਰਨ 'ਤੇ ਵੀ ਕੰਮ ਕਰ ਰਹੀ ਹੈ।

ਸੰਪਾਦਕ ਦੇ ਐਨ.ਬੀ.: ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕੁਬਰਨੇਟਸ ਤਕਨਾਲੋਜੀ ਬਾਰੇ ਸੁਣਿਆ ਹੈ (ਅਤੇ ਮੈਨੂੰ ਕੋਈ ਸ਼ੱਕ ਨਹੀਂ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਹੈ), ਪਰ ਅਜੇ ਤੱਕ ਇਸਨੂੰ ਆਪਣੇ ਹੱਥਾਂ ਨਾਲ ਨਹੀਂ ਛੂਹਿਆ ਹੈ, ਤਾਂ ਮੈਂ ਔਨਲਾਈਨ ਤੀਬਰ ਕੋਰਸਾਂ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ ਕੁਬਰਨੇਟਸ ਬੇਸ, ਜੋ ਕਿ ਸਤੰਬਰ 28-30 ਨੂੰ ਆਯੋਜਿਤ ਕੀਤਾ ਜਾਵੇਗਾ, ਅਤੇ ਕੁਬਰਨੇਟਸ ਮੈਗਾ, ਜੋ 14-16 ਅਕਤੂਬਰ ਨੂੰ ਹੋਵੇਗਾ। ਇਹ ਤੁਹਾਨੂੰ ਭਰੋਸੇ ਨਾਲ ਨੈਵੀਗੇਟ ਕਰਨ ਅਤੇ ਤਕਨਾਲੋਜੀ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ।

ਇਹ ਦੋ ਪਹੁੰਚ ਹਨ ਜੋ ਇੱਕੋ ਟੀਚੇ ਦਾ ਪਿੱਛਾ ਕਰਦੇ ਹਨ: gitlab.com ਲਈ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਸਹੂਲਤਾਂ 'ਤੇ ਗਾਹਕਾਂ ਲਈ ਅਪਡੇਟਾਂ ਦੀ ਤੇਜ਼ ਡਿਲੀਵਰੀ।

ਸਾਡੇ ਲਈ ਕੋਈ ਵਿਚਾਰ ਜਾਂ ਸਿਫ਼ਾਰਸ਼ਾਂ?

GitLab ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਉਣ ਲਈ ਹਰ ਕਿਸੇ ਦਾ ਸੁਆਗਤ ਹੈ, ਅਤੇ ਅਸੀਂ ਆਪਣੇ ਪਾਠਕਾਂ ਤੋਂ ਫੀਡਬੈਕ ਦਾ ਸੁਆਗਤ ਕਰਦੇ ਹਾਂ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਸਾਡੀ ਡਿਲੀਵਰੀ ਟੀਮ ਲਈ ਕੋਈ ਵਿਚਾਰ ਹਨ, ਤਾਂ ਸੰਕੋਚ ਨਾ ਕਰੋ ਇੱਕ ਬੇਨਤੀ ਬਣਾਓ ਨੋਟਿਸ ਦੇ ਨਾਲ team: Delivery.

ਸਰੋਤ: www.habr.com