DevOpsForum 2019। ਤੁਸੀਂ DevOps ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਇੰਤਜ਼ਾਰ ਨਹੀਂ ਕਰ ਸਕਦੇ

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

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

Raiffeisenbank, Alfastrakhovanie, Mango Telecom ਦੇ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਤਜ਼ਰਬੇ ਅਤੇ ਕੱਟ ਦੇ ਅਧੀਨ ਹੋਰ ਵੇਰਵਿਆਂ ਦੇ ਭਾਸ਼ਣਾਂ ਦਾ ਇੱਕ ਅੰਸ਼।

ਮੇਰਾ ਨਾਮ ਯਾਨਾ ਹੈ, ਮੈਂ ਇੱਕ ਟੈਸਟਰ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹਾਂ, ਮੈਂ ਆਟੋਮੇਸ਼ਨ ਕਰਦਾ ਹਾਂ, ਨਾਲ ਹੀ DevOps, ਅਤੇ ਮੈਨੂੰ ਕਾਨਫਰੰਸਾਂ ਅਤੇ ਮੀਟਿੰਗਾਂ ਵਿੱਚ ਜਾਣਾ ਪਸੰਦ ਹੈ। ਪਿਛਲੇ ਦੋ ਸਾਲਾਂ ਵਿੱਚ, ਮੈਂ ਓਲੇਗ ਬੁਨਿਨ ਦੀਆਂ ਕਾਨਫਰੰਸਾਂ (ਹਾਈਲੋਡ++, ਟੀਮਲੀਡ ਕਨਫ), ਜੱਗ ਇਵੈਂਟਸ (ਹੇਜ਼ਨਬੱਗ, ਜੇਪੁਆਇੰਟ), ਟੈਸਟਕਾਨ ਮਾਸਕੋ, ਡੇਵੋਪਸ ਪ੍ਰੋ ਮਾਸਕੋ, ਬਿਗ ਡੇਟਾ ਮਾਸਕੋ ਵਿੱਚ ਗਿਆ ਹਾਂ।

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

Raiffeisenbank 'ਤੇ ਪਾਈਪਲਾਈਨ ਦੇ ਅੰਤ 'ਤੇ ਰੌਸ਼ਨੀ

ਆਮ ਤੌਰ 'ਤੇ, ਮੈਂ ਉਨ੍ਹਾਂ ਸਪੀਕਰਾਂ ਦੀ ਭਾਲ ਕਰਦਾ ਹਾਂ ਜੋ ਮੇਰੀ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਨ। DevOpsForum 2019 'ਤੇ, Raiffeisenbank, Mikhail Bizhan ਦੇ ਇੱਕ ਸਪੀਕਰ ਨੇ ਮੇਰੀ ਦਿਲਚਸਪੀ ਲਈ। ਆਪਣੇ ਭਾਸ਼ਣ ਦੇ ਦੌਰਾਨ, ਉਸਨੇ ਇਸ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਕਿ ਉਹ ਕਿਵੇਂ ਹੌਲੀ-ਹੌਲੀ ਆਪਣੀਆਂ ਟੀਮਾਂ ਨੂੰ DevOps 'ਤੇ ਜੋੜ ਰਹੇ ਹਨ, ਉਨ੍ਹਾਂ ਨੂੰ ਇਸਦੀ ਕਿਉਂ ਲੋੜ ਹੈ, ਅਤੇ DevOps ਦੇ ਰੂਪਾਂਤਰਣ ਦੇ ਵਿਚਾਰ ਨੂੰ ਕਾਰੋਬਾਰ ਵਿੱਚ ਕਿਵੇਂ ਵੇਚਣਾ ਹੈ। ਖੈਰ, ਆਮ ਤੌਰ 'ਤੇ, ਮੈਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਕਿ ਪਾਈਪਲਾਈਨ ਦੇ ਅੰਤ 'ਤੇ ਰੌਸ਼ਨੀ ਨੂੰ ਕਿਵੇਂ ਵੇਖਣਾ ਹੈ.

ਮਿਖਾਇਲ ਬਿਜ਼ਾਨ, ਰਾਇਫੀਸੇਨਬੈਂਕ ਵਿਖੇ ਆਟੋਮੇਸ਼ਨ ਦੇ ਨਿਰਦੇਸ਼ਕ

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

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

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

ਆਮ ਤੌਰ 'ਤੇ, ਮੀਸ਼ਾ ਦਾ ਮੰਨਣਾ ਹੈ ਕਿ DevOps ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਪਰ ਸਮਝਦਾਰੀ ਨਾਲ. ਅਤੇ ਸਾਨੂੰ ਇਸ ਤੱਥ ਲਈ ਤਿਆਰ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਤਬਦੀਲੀ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਟੀਮ ਦੀ ਉਤਪਾਦਕਤਾ ਘੱਟ ਜਾਵੇਗੀ, ਇਹ ਘੱਟ ਪੈਸੇ ਕਮਾਏਗੀ, ਪਰ ਫਿਰ ਇਹ ਜਾਇਜ਼ ਹੋਵੇਗਾ.

ਮੈਂਗੋ ਟੈਲੀਕਾਮ 'ਤੇ ਟੈਸਟਿੰਗ ਦਾ ਆਟੋਮੇਸ਼ਨ

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

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

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

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

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

ਅਲਫਾਸਟ੍ਰਾਖੋਵਨੀ ਵਿਖੇ ਵਿਕਾਸ ਨਿਰਦੇਸ਼ਕ ਨਾਲ ਗੋਲ ਟੇਬਲ ਅਤੇ DevOps ਮੁੱਦੇ

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

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

ਫਿਰ, ਮੈਂ ਐਂਟਨ ਇਸਾਨਿਨ ਨਾਲ ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਗੱਲ ਕੀਤੀ. ਅਸੀਂ DevOps ਸੱਭਿਆਚਾਰ ਨੂੰ ਹਰ ਘਰ ਤੱਕ ਪਹੁੰਚਾਉਣ ਦੀ ਲੋੜ 'ਤੇ ਚਰਚਾ ਕੀਤੀ ਅਤੇ DevOps ਪਰਿਵਰਤਨ ਦੇ ਹਨੇਰੇ ਪੱਖ ਨੂੰ ਉਜਾਗਰ ਕੀਤਾ।

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

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

ਸਰੋਤ: www.habr.com