DevOps LEGO: ਅਸੀਂ ਪਾਈਪਲਾਈਨ ਨੂੰ ਕਿਊਬ ਵਿੱਚ ਕਿਵੇਂ ਵਿਛਾਇਆ

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

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

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

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

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

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

ਇਸ ਲਈ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਪਾਸੇ ਸਮੱਸਿਆਵਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ, ਦੂਜੇ ਪਾਸੇ ਸਾਡੇ ਕੋਲ DevOps ਗਿਆਨ, ਅਭਿਆਸ ਅਤੇ ਸਾਧਨ ਹਨ. ਕਿਉਂ ਨਾ ਹਰ ਕਿਸੇ ਨਾਲ ਅਨੁਭਵ ਸਾਂਝਾ ਕਰੋ?

ਇੱਕ DevOps ਕੰਸਟਰਕਟਰ ਬਣਾਉਣਾ

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

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

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

ਪ੍ਰਕਿਰਿਆਵਾਂ

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

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

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

ਸਭਿਆਚਾਰ

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

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

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

ਲੋਕ

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

ਤਕਨਾਲੋਜੀ ਦੇ

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

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

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

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

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

ਨਿਰੰਤਰ ਡਿਲਿਵਰੀ ਅਤੇ ਨਿਗਰਾਨੀ

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

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

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

ਕਿਸ ਨੂੰ ਸਾਡੀ ਲੋੜ ਹੋਵੇਗੀ DevOps ਡਿਜ਼ਾਈਨਰ?

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

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

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

ਸਰੋਤ: www.habr.com