DevOps ਕੀ ਹੈ

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

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

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

ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਨਾਲ, ਮੈਂ DevOps ਮਾਸਕੋ ਕਮਿਊਨਿਟੀ ਦੇ ਪ੍ਰਬੰਧਕਾਂ ਅਤੇ DevOps-Days 2017 ਦੇ ਪ੍ਰਬੰਧਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹਾਂ, ਪਰ ਮੈਂ 2018 ਦਾ ਆਯੋਜਨ ਨਹੀਂ ਕੀਤਾ। ਐਕਸਪ੍ਰੈਸ 42 ਕਈ ਕੰਪਨੀਆਂ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਉੱਥੇ DevOps ਵਧਾਉਂਦੇ ਹਾਂ, ਦੇਖਦੇ ਹਾਂ ਕਿ ਇਹ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ, ਸਿੱਟੇ ਕੱਢਦੇ ਹਾਂ, ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਹਾਂ, ਸਾਰਿਆਂ ਨੂੰ ਸਾਡੇ ਸਿੱਟੇ ਦੱਸਦੇ ਹਾਂ, ਅਤੇ ਲੋਕਾਂ ਨੂੰ DevOps ਅਭਿਆਸਾਂ ਵਿੱਚ ਸਿਖਲਾਈ ਦਿੰਦੇ ਹਾਂ। ਆਮ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਇਸ ਸਬੰਧ ਵਿੱਚ ਆਪਣੇ ਅਨੁਭਵ ਅਤੇ ਮੁਹਾਰਤ ਨੂੰ ਵਧਾਉਣ ਲਈ ਆਪਣੀ ਪੂਰੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ।

DevOps ਕਿਉਂ

ਪਹਿਲਾ ਸਵਾਲ ਜੋ ਹਰ ਕਿਸੇ ਨੂੰ ਪਰੇਸ਼ਾਨ ਕਰਦਾ ਹੈ ਅਤੇ ਹਮੇਸ਼ਾ ਹੁੰਦਾ ਹੈ - ਕਿਉਂ? ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਸੋਚਦੇ ਹਨ ਕਿ DevOps ਸਿਰਫ਼ ਆਟੋਮੇਸ਼ਨ ਜਾਂ ਇੱਕ ਸਮਾਨ ਚੀਜ਼ ਹੈ ਜੋ ਹਰ ਕੰਪਨੀ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਸੀ.

— ਸਾਡੇ ਕੋਲ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਸੀ - ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ DevOps ਸਨ, ਅਤੇ ਇਹ ਸਭ ਕੁਝ ਕਿਉਂ ਲੋੜੀਂਦਾ ਹੈ? ਉਹ ਵਿਦੇਸ਼ ਵਿੱਚ ਮਸਤੀ ਕਰ ਰਹੇ ਹਨ, ਪਰ ਉਹ ਸਾਨੂੰ ਕੰਮ ਕਰਨ ਤੋਂ ਰੋਕ ਰਹੇ ਹਨ!

ਕਮਿਊਨਿਟੀ ਅਤੇ ਵਿਧੀ ਦੇ ਵਿਕਾਸ ਦੇ 9 ਸਾਲਾਂ ਤੋਂ ਵੱਧ, ਇਹ ਪਹਿਲਾਂ ਹੀ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਹੈ ਕਿ ਇਹ ਅਜੇ ਵੀ ਮਾਰਕੀਟਿੰਗ ਚਮਕ ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਅਜੇ ਵੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ ਕਿ ਇਸਦੀ ਲੋੜ ਕਿਉਂ ਹੈ. ਕਿਸੇ ਵੀ ਟੂਲ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਦੀ ਤਰ੍ਹਾਂ, DevOps ਦੇ ਖਾਸ ਟੀਚੇ ਹਨ ਜੋ ਇਹ ਆਖਰਕਾਰ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ।

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

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

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

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

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

ਇਹ ਉਤਪਾਦ ਯੂਨੀਲੀਵਰ ਦੁਆਰਾ $1 ਬਿਲੀਅਨ ਵਿੱਚ ਖਰੀਦਿਆ ਗਿਆ ਸੀ। ਇਹ ਹੁਣ ਜਿਲੇਟ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦਾ ਹੈ ਅਤੇ ਅਮਰੀਕੀ ਬਾਜ਼ਾਰ ਵਿੱਚ ਖਪਤਕਾਰਾਂ ਦਾ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਖੋਹ ਲੈਂਦਾ ਹੈ। ਇੱਕ ਬਾਕਸ ਸ਼ੇਵ ਕਹੋ:

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

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

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

ਟਾਈਮ-ਟੂ-ਮਾਰਕੀਟ ਵਿਚਾਰ ਤੋਂ ਅੰਤਮ ਲਾਗੂ ਕਰਨ ਤੱਕ ਦੇ ਸਮੇਂ ਨੂੰ ਘੱਟ ਕਰਨ ਬਾਰੇ ਹੈ।

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

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

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

1968 ਵਿੱਚ, ਇੱਕ ਦੂਰਦਰਸ਼ੀ ਵਿਅਕਤੀ, ਮੇਲਵਿਨ ਕੋਨਵੇ, ਨੇ ਹੇਠਾਂ ਦਿੱਤੇ ਵਿਚਾਰ ਨੂੰ ਤਿਆਰ ਕੀਤਾ।

ਉਹ ਸੰਗਠਨ ਜੋ ਸਿਸਟਮ ਬਣਾਉਂਦਾ ਹੈ ਇੱਕ ਡਿਜ਼ਾਈਨ ਦੁਆਰਾ ਸੀਮਤ ਹੈ ਜੋ ਉਸ ਸੰਗਠਨ ਦੇ ਸੰਚਾਰ ਢਾਂਚੇ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ।

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

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

ਪ੍ਰਕਿਰਿਆ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, DevOps ਤੋਂ ਪਹਿਲਾਂ, ਸਾਰੇ ਪੜਾਅ: ਵਿਸ਼ਲੇਸ਼ਣ, ਵਿਕਾਸ, ਟੈਸਟਿੰਗ, ਸੰਚਾਲਨ, ਰੇਖਿਕ ਸਨ।
DevOps ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇਹ ਸਾਰੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਇੱਕੋ ਸਮੇਂ ਹੁੰਦੀਆਂ ਹਨ।

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

ਤਾਂ ਤੁਹਾਨੂੰ DevOps ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?

ਡਿਜੀਟਲ ਉਤਪਾਦ ਵਿਕਾਸ ਲਈ. ਜੇ ਤੁਹਾਡੀ ਕੰਪਨੀ ਕੋਲ ਡਿਜੀਟਲ ਉਤਪਾਦ ਨਹੀਂ ਹੈ, ਤਾਂ DevOps ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ - ਇਹ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ.

DevOps ਕ੍ਰਮਵਾਰ ਸੌਫਟਵੇਅਰ ਉਤਪਾਦਨ ਦੀਆਂ ਗਤੀ ਸੀਮਾਵਾਂ ਨੂੰ ਪਾਰ ਕਰਦਾ ਹੈ. ਇਸ ਵਿੱਚ ਸਾਰੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਇੱਕੋ ਸਮੇਂ ਹੁੰਦੀਆਂ ਹਨ।

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

DevOps ਦੇ ਨਾਲ, ਚੀਜ਼ਾਂ ਸਿਰਫ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਣਗੀਆਂ.

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

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

ਇੱਕ ਮਾਹਰ ਲਈ ਸਵਾਲ

ਤੁਹਾਡੇ ਕੋਲ ਕੀ ਹੈ? ਸਵਾਲ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਕੰਪਨੀ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹੋਏ ਅਤੇ ਇੱਕ ਮਾਹਰ ਦੇ ਰੂਪ ਵਿੱਚ ਵਿਕਾਸ ਕਰਦੇ ਸਮੇਂ ਆਪਣੇ ਆਪ ਤੋਂ ਪੁੱਛ ਸਕਦੇ ਹੋ।

ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਡਿਜੀਟਲ ਉਤਪਾਦ ਬਣਾਉਣ ਲਈ ਕੋਈ ਰਣਨੀਤੀ ਹੈ? ਜੇ ਹੈ, ਤਾਂ ਇਹ ਪਹਿਲਾਂ ਹੀ ਚੰਗਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੀ ਕੰਪਨੀ DevOps ਵੱਲ ਵਧ ਰਹੀ ਹੈ।

ਕੀ ਤੁਹਾਡੀ ਕੰਪਨੀ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਡਿਜੀਟਲ ਉਤਪਾਦ ਬਣਾ ਰਹੀ ਹੈ? ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਹੋਰ ਪੱਧਰ ਉੱਚਾ ਚੁੱਕ ਸਕਦੇ ਹੋ ਅਤੇ ਚੀਜ਼ਾਂ ਨੂੰ ਹੋਰ ਦਿਲਚਸਪ ਢੰਗ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ - ਦੁਬਾਰਾ ਇੱਕ DevOps ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ। ਮੈਂ ਸਿਰਫ ਇਸ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਗੱਲ ਕਰ ਰਿਹਾ ਹਾਂ.

ਕੀ ਤੁਹਾਡੀ ਕੰਪਨੀ ਡਿਜੀਟਲ ਉਤਪਾਦ ਸਥਾਨ ਵਿੱਚ ਮਾਰਕੀਟ ਲੀਡਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ? Spotify, Yandex, Uber ਉਹ ਕੰਪਨੀਆਂ ਹਨ ਜੋ ਹੁਣ ਤਕਨੀਕੀ ਤਰੱਕੀ ਦੇ ਸਿਖਰ 'ਤੇ ਹਨ।

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

ਸੰਗਠਨ ਨੂੰ

ਜਿਵੇਂ ਕਿ ਮੈਂ ਕਿਹਾ, ਕੋਨਵੇ ਦੇ ਕਾਨੂੰਨ ਦੇ ਅਨੁਸਾਰ, ਇੱਕ ਕੰਪਨੀ ਦਾ ਸੰਗਠਨ ਬਦਲਦਾ ਹੈ. ਮੈਂ ਉਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰਾਂਗਾ ਜੋ DevOps ਨੂੰ ਸੰਗਠਨਾਤਮਕ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਕੰਪਨੀ ਦੇ ਅੰਦਰ ਦਾਖਲ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ.

"ਖੂਹਾਂ" ਦੀ ਸਮੱਸਿਆ

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

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

DevOps ਇਹ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਕਿ ਭਟਕਣਾ ਦੇ ਇਸ ਪਲ ਵਿੱਚੋਂ ਲੰਘਣ ਅਤੇ ਸਾਰੇ ਵਿਭਾਗ ਇੱਕ ਸਾਂਝਾ ਇੰਟਰੈਕਸ਼ਨ ਮੈਪ ਬਣਾਉਣ ਲਈ ਮਿਲ ਕੇ ਕੰਮ ਕਰਦੇ ਹਨ।

ਦੋ ਕਾਰਕ ਇਸ ਵਿੱਚ ਰੁਕਾਵਟ ਪਾਉਂਦੇ ਹਨ।

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

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

- ਅਸੀਂ ਸਿਰਫ CI ਲਾਂਚ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ, ਪਰ ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਪ੍ਰਬੰਧਨ ਨੂੰ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਸੀ।

ਇਹ ਬਿਲਕੁਲ ਇਸ ਲਈ ਵਾਪਰਦਾ ਹੈ ਕਿਉਂਕਿ CI и ਨਿਰੰਤਰ ਡਿਲਿਵਰੀ ਪ੍ਰਕਿਰਿਆ ਬਹੁਤ ਸਾਰੀਆਂ ਪ੍ਰੀਖਿਆਵਾਂ ਦੀ ਸਰਹੱਦ 'ਤੇ ਹਨ। ਸਿਰਫ਼ ਸੰਗਠਨਾਤਮਕ ਪੱਧਰ 'ਤੇ "ਖੂਹਾਂ" ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਦੂਰ ਕੀਤੇ ਬਿਨਾਂ, ਤੁਸੀਂ ਅੱਗੇ ਨਹੀਂ ਵਧ ਸਕੋਗੇ, ਭਾਵੇਂ ਤੁਸੀਂ ਜੋ ਵੀ ਕਰਦੇ ਹੋ ਅਤੇ ਭਾਵੇਂ ਇਹ ਕਿੰਨਾ ਵੀ ਉਦਾਸ ਕਿਉਂ ਨਾ ਹੋਵੇ।

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

ਲੋਕ ਕਿਸੇ ਨਾ ਕਿਸੇ ਸਿਤਾਰੇ ਜਾਂ ਝੰਡੇ ਲਈ ਲੜ ਰਹੇ ਹਨ, ਹਰ ਕੋਈ ਆਪਣੀ ਮੁਹਾਰਤ ਪੁੱਟ ਰਿਹਾ ਹੈ।

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

ਕੀ ਇਹ ਤੁਹਾਡੀ ਕੰਪਨੀ ਵਿੱਚ ਇੱਕੋ ਜਿਹਾ ਹੈ?

ਇਸਦੀ ਜਾਂਚ ਕਰਨ ਲਈ, ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਸਵਾਲ ਪੁੱਛ ਸਕਦੇ ਹੋ।

ਕੀ ਟੀਮਾਂ ਸਾਂਝੇ ਸਾਧਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਉਹਨਾਂ ਆਮ ਸਾਧਨਾਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਉਂਦੀਆਂ ਹਨ?

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

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

ਪ੍ਰਬੰਧਕਾਂ ਲਈ ਕੰਪਨੀ ਦੀਆਂ ਪ੍ਰਾਪਤੀਆਂ 'ਤੇ ਵਿਚਾਰ ਕੀਤੇ ਬਿਨਾਂ ਨਿੱਜੀ ਪ੍ਰਾਪਤੀਆਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਕਿੰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ?

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

ਕੋਡ ਦੇ ਤੌਰ 'ਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚਾ

ਇਸ ਸਮੱਸਿਆ ਦੇ ਪਾਸ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਪਹਿਲਾ ਮਹੱਤਵਪੂਰਨ ਅਭਿਆਸ, ਜਿਸ ਤੋਂ ਬਿਨਾਂ DevOps ਵਿੱਚ ਅੱਗੇ ਵਧਣਾ ਮੁਸ਼ਕਲ ਹੈ, ਹੈ ਕੋਡ ਦੇ ਰੂਪ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚਾ.

ਬਹੁਤੇ ਅਕਸਰ, ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਕੋਡ ਵਜੋਂ ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ:

- ਆਓ ਬੈਸ਼ ਵਿੱਚ ਹਰ ਚੀਜ਼ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰੀਏ, ਆਪਣੇ ਆਪ ਨੂੰ ਸਕ੍ਰਿਪਟਾਂ ਨਾਲ ਕਵਰ ਕਰੀਏ ਤਾਂ ਕਿ ਪ੍ਰਬੰਧਕਾਂ ਕੋਲ ਘੱਟ ਹੱਥੀਂ ਕੰਮ ਹੋਵੇ!

ਪਰ ਇਹ ਸੱਚ ਨਹੀਂ ਹੈ।

ਕੋਡ ਦੇ ਰੂਪ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਉਸ IT ਸਿਸਟਮ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹੋ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਕੋਡ ਦੇ ਰੂਪ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹੋ ਤਾਂ ਕਿ ਇਸਦੀ ਸਥਿਤੀ ਨੂੰ ਲਗਾਤਾਰ ਸਮਝਿਆ ਜਾ ਸਕੇ।

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

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

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

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

ਕੋਡ ਨੂੰ ਸਰਵੋਤਮ ਕੋਡ ਅਭਿਆਸਾਂ ਦੇ ਅਨੁਸਾਰ ਬਣਾਈ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ: ਸੰਯੁਕਤ ਵਿਕਾਸ, ਕੋਡ ਸਮੀਖਿਆ, XP-ਪ੍ਰੋਗਰਾਮਿੰਗ, ਟੈਸਟਿੰਗ, ਪੁੱਲ ਬੇਨਤੀਆਂ, ਕੋਡ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ CI - ਇਹ ਸਭ ਢੁਕਵਾਂ ਹੈ ਅਤੇ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਕੋਡ ਸਾਰੇ ਇੰਜੀਨੀਅਰਾਂ ਲਈ ਇੱਕ ਸਾਂਝੀ ਭਾਸ਼ਾ ਬਣ ਜਾਂਦਾ ਹੈ।

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

ਮਹੱਤਵਪੂਰਣ: ਜੇਕਰ ਤੁਸੀਂ ਅਜੇ ਤੱਕ ਇਸ ਚੀਜ਼ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕੀਤੀ ਹੈ, ਤਾਂ ਯਾਦ ਰੱਖੋ ਜਵਾਬਦੇਹ ਬਾਸ਼ ਨਹੀਂ ਹੈ! ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਧਿਆਨ ਨਾਲ ਪੜ੍ਹੋ, ਅਧਿਐਨ ਕਰੋ ਕਿ ਉਹ ਇਸ ਬਾਰੇ ਕੀ ਲਿਖਦੇ ਹਨ।

ਕੋਡ ਦੇ ਰੂਪ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਕੋਡ ਨੂੰ ਵੱਖਰੀਆਂ ਪਰਤਾਂ ਵਿੱਚ ਵੱਖ ਕਰਨਾ ਹੈ।

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


ਅਧਾਰ ਪਰਤ - ਇਸ ਤਰ੍ਹਾਂ OS, ਬੈਕਅੱਪ ਅਤੇ ਹੋਰ ਨੀਵੇਂ-ਪੱਧਰ ਦੀਆਂ ਚੀਜ਼ਾਂ ਦੀ ਸੰਰਚਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ, Kubernetes ਨੂੰ ਬੁਨਿਆਦੀ ਪੱਧਰ 'ਤੇ ਕਿਵੇਂ ਤੈਨਾਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

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

ਉਹ ਪਰਤ ਜਿੱਥੇ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਏ ਜਾਂਦੇ ਹਨ ਅਤੇ ਦੱਸਦਾ ਹੈ ਕਿ ਉਹ ਪਿਛਲੀਆਂ ਦੋ ਪਰਤਾਂ ਦੇ ਸਿਖਰ 'ਤੇ ਕਿਵੇਂ ਪ੍ਰਗਟ ਹੋਣਗੇ।

ਸਵਾਲਾਂ ਨੂੰ ਕੰਟਰੋਲ ਕਰੋ

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

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

ਲਗਾਤਾਰ ਡਿਲਿਵਰੀ

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

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

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

ਨਿਰੰਤਰ ਪਹੁੰਚਾਉਣ ਦੇ ਸਾਧਨ

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

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

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

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

ਵੱਖ-ਵੱਖ ਤੈਨਾਤੀ ਰਣਨੀਤੀਆਂ। ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ AB ਟੈਸਟਿੰਗ ਜਾਂ ਕੈਨਰੀ ਤੈਨਾਤੀਆਂ ਦੀ ਵਰਤੋਂ ਵੱਖ-ਵੱਖ ਗਾਹਕਾਂ 'ਤੇ ਕੋਡ ਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਟੈਸਟ ਕਰਨ ਲਈ ਕਰਦੇ ਹੋ, ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ ਕਿ ਕੋਡ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ 100 ਮਿਲੀਅਨ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਰੋਲਆਊਟ ਕੀਤੇ ਜਾਣ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ।

"ਲਗਾਤਾਰ ਡਿਲੀਵਰ" ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ।

ਡਿਲੀਵਰੀ ਪ੍ਰਕਿਰਿਆ Dev, CI, Test, PreProd, Prod ਇੱਕ ਵੱਖਰਾ ਵਾਤਾਵਰਣ ਨਹੀਂ ਹੈ, ਇਹ ਫਾਇਰਪਰੂਫ ਰਕਮਾਂ ਵਾਲੇ ਪੜਾਅ ਜਾਂ ਸਟੇਸ਼ਨ ਹਨ ਜਿੱਥੋਂ ਤੁਹਾਡੀ ਆਰਟੀਫੈਕਟ ਲੰਘਦਾ ਹੈ।

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

ਸਵੈ-ਜਾਂਚ ਲਈ ਸਵਾਲ

95% ਕੇਸਾਂ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾ ਵਰਣਨ ਤੋਂ ਉਤਪਾਦਨ ਵਿੱਚ ਜਾਰੀ ਕਰਨ ਦਾ ਸਮਾਂ ਇੱਕ ਹਫ਼ਤੇ ਤੋਂ ਘੱਟ ਹੈ? ਕੀ ਪਾਈਪਲਾਈਨ ਦੇ ਹਰੇਕ ਪੜਾਅ 'ਤੇ ਆਰਟੀਫੈਕਟ ਦੀ ਗੁਣਵੱਤਾ ਵਿੱਚ ਸੁਧਾਰ ਹੁੰਦਾ ਹੈ? ਕੀ ਕੋਈ ਕਹਾਣੀ ਹੈ ਜੋ ਇਹ ਲੰਘਦੀ ਹੈ? ਕੀ ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਤੈਨਾਤੀ ਰਣਨੀਤੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ?

ਜੇ ਸਾਰੇ ਜਵਾਬ ਹਾਂ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਅਵਿਸ਼ਵਾਸ਼ਯੋਗ ਤੌਰ 'ਤੇ ਠੰਡਾ ਹੋ! ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਆਪਣੇ ਜਵਾਬ ਲਿਖੋ - ਮੈਨੂੰ ਖੁਸ਼ੀ ਹੋਵੇਗੀ).

ਸੁਝਾਅ

ਇਹ ਸਭ ਤੋਂ ਔਖਾ ਅਭਿਆਸ ਹੈ। DevOpsConf ਕਾਨਫਰੰਸ ਵਿੱਚ, Infobip ਦੇ ਇੱਕ ਸਹਿਯੋਗੀ, ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹੋਏ, ਉਸਦੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਥੋੜਾ ਜਿਹਾ ਉਲਝਣ ਵਿੱਚ ਸੀ, ਕਿਉਂਕਿ ਇਹ ਅਸਲ ਵਿੱਚ ਇਸ ਤੱਥ ਬਾਰੇ ਇੱਕ ਬਹੁਤ ਹੀ ਗੁੰਝਲਦਾਰ ਅਭਿਆਸ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਹਰ ਚੀਜ਼ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ!

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

- ਦੋਸਤੋ, ਤੁਸੀਂ ਸਰਵਰ ਨਾਲ ਕਿਸੇ ਅਸਪਸ਼ਟ ਚੀਜ਼ ਨਾਲ ਬਲਾਤਕਾਰ ਕਿਉਂ ਕਰ ਰਹੇ ਹੋ?

ਪਰ ਫਿਰ ਇੱਕ ਘਟਨਾ ਵਾਪਰੀ ਜਿਸ ਨੇ ਦਿਖਾਇਆ ਕਿ ਇਹ ਅਸਲ ਵਿੱਚ ਇੱਕ ਬਹੁਤ ਵਧੀਆ ਰਣਨੀਤੀ ਹੈ.

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

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

- ਦੋਸਤੋ, ਡੇਢ ਹਫ਼ਤਾ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਕੀ ਹੋਇਆ ਸੀ?

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

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

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

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

ਨਹੀਂ ਤਾਂ ਇਸਦਾ ਪਤਾ ਲਗਾਉਣਾ ਮੁਸ਼ਕਲ ਹੋਵੇਗਾ. ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਕਿਹਾ ਹੈ ਕਿ DevOps ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਹੈ. ਇਸ ਗੁੰਝਲਤਾ ਨਾਲ ਸਿੱਝਣ ਲਈ, ਤੁਹਾਨੂੰ ਸਾਧਾਰਨ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਦੀ ਲੋੜ ਹੈ.

ਸਵੈ-ਨਿਯੰਤਰਣ ਲਈ ਸਵਾਲ

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

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

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

ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪਲੇਟਫਾਰਮ

ਬਿੰਦੂ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਵੱਖ-ਵੱਖ ਸਾਧਨਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ ਜੋ ਹਰ ਕੰਪਨੀ ਕੋਲ ਹੈ.

ਇੱਕ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪਲੇਟਫਾਰਮ ਦਾ ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਸਾਰੀਆਂ ਟੀਮਾਂ ਇਹਨਾਂ ਸਾਧਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇਕੱਠੇ ਵਿਕਸਿਤ ਕਰਦੀਆਂ ਹਨ.

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

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

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

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

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

ਸਕੀਮ

ਇਹ ਇੱਕ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪਲੇਟਫਾਰਮ ਦਾ ਇੱਕ ਬੁਨਿਆਦੀ ਚਿੱਤਰ ਹੈ ਜੋ ਇੱਕ DevOps ਕੰਪਨੀ ਵਿੱਚ ਸਾਰੇ ਅਭਿਆਸਾਂ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰੇਗਾ।

ਆਓ ਦੇਖੀਏ ਕਿ ਇਸ ਵਿੱਚ ਕੀ ਸ਼ਾਮਲ ਹੈ।

ਸਰੋਤ ਆਰਕੈਸਟਰੇਸ਼ਨ ਸਿਸਟਮ, ਜੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਤੇ ਹੋਰ ਸੇਵਾਵਾਂ ਨੂੰ CPU, ਮੈਮੋਰੀ, ਡਿਸਕ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਸ ਦੇ ਸਿਖਰ 'ਤੇ - ਨੀਵੇਂ ਪੱਧਰ ਦੀਆਂ ਸੇਵਾਵਾਂ: ਨਿਗਰਾਨੀ, ਲੌਗਿੰਗ, CI/CD ਇੰਜਣ, ਆਰਟੀਫੈਕਟ ਸਟੋਰੇਜ, ਸਿਸਟਮ ਕੋਡ ਦੇ ਤੌਰ 'ਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚਾ।

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

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

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

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

ਪਲੇਟਫਾਰਮ ਦੀ ਸਿਰਜਣਾ

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

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

ਤੁਹਾਡੇ ਕੋਲ ਕੀ ਹੈ?

ਦੁਬਾਰਾ ਫਿਰ, ਸਵਾਲ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਤੋਂ ਪੁੱਛ ਸਕਦੇ ਹੋ।

ਕੀ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪਲੇਟਫਾਰਮ ਸਮਰਪਿਤ ਹੈ? ਇਸ ਦੇ ਵਿਕਾਸ ਲਈ ਕੌਣ ਜ਼ਿੰਮੇਵਾਰ ਹੈ? ਕੀ ਤੁਸੀਂ ਆਪਣੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਪਲੇਟਫਾਰਮ ਦੇ ਪ੍ਰਤੀਯੋਗੀ ਫਾਇਦਿਆਂ ਨੂੰ ਸਮਝਦੇ ਹੋ?

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

ਇਸ ਲਈ, DevOps...

... ਇਹ ਇੱਕ ਗੁੰਝਲਦਾਰ ਪ੍ਰਣਾਲੀ ਹੈ, ਇਸ ਵਿੱਚ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

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

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

ਇਹ ਇੱਕ ਦੋ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਖਤਮ ਹੋ ਜਾਵੇਗਾ DevOpsConf 2019. RIT++ ਦੇ ਹਿੱਸੇ ਵਜੋਂ। ਕਾਨਫਰੰਸ ਵਿੱਚ ਆਓ, ਜਿੱਥੇ ਤੁਹਾਨੂੰ ਲਗਾਤਾਰ ਡਿਲੀਵਰੀ, ਕੋਡ ਦੇ ਰੂਪ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਅਤੇ DevOps ਪਰਿਵਰਤਨ ਬਾਰੇ ਬਹੁਤ ਸਾਰੀਆਂ ਸ਼ਾਨਦਾਰ ਰਿਪੋਰਟਾਂ ਮਿਲਣਗੀਆਂ। ਆਪਣੀਆਂ ਟਿਕਟਾਂ ਬੁੱਕ ਕਰੋ, ਆਖਰੀ ਕੀਮਤ ਦੀ ਆਖਰੀ ਮਿਤੀ 20 ਮਈ ਹੈ

ਸਰੋਤ: www.habr.com