DevOps ਕੌਣ ਹੈ ਅਤੇ ਇਸਦੀ ਕਦੋਂ ਲੋੜ ਨਹੀਂ ਹੈ?

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

ਕੁਝ ਲੋਕ ਆਪਣੇ ਰੈਜ਼ਿਊਮੇ 'ਤੇ DevOps ਦੀ ਸੂਚੀ ਦਿੰਦੇ ਹਨ, ਹਾਲਾਂਕਿ ਉਹ ਹਮੇਸ਼ਾ ਸ਼ਬਦ ਦੇ ਤੱਤ ਨੂੰ ਨਹੀਂ ਜਾਣਦੇ ਜਾਂ ਸਮਝਦੇ ਨਹੀਂ ਹਨ। ਕੁਝ ਲੋਕ ਸੋਚਦੇ ਹਨ ਕਿ Ansible, GitLab, Jenkins, Terraform ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਅਧਿਐਨ ਕਰਨ ਤੋਂ ਬਾਅਦ (ਸੂਚੀ ਨੂੰ ਤੁਹਾਡੇ ਸੁਆਦ ਦੇ ਅਨੁਸਾਰ ਜਾਰੀ ਰੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ), ਤੁਸੀਂ ਤੁਰੰਤ ਇੱਕ "ਡਿਪੋਸਿਸਟ" ਬਣ ਜਾਓਗੇ। ਇਹ, ਬੇਸ਼ੱਕ, ਸੱਚ ਨਹੀਂ ਹੈ।

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

DevOps ਕੌਣ ਹੈ

ਇੱਕ ਲੇਖ ਲਿਖਣ ਦਾ ਵਿਚਾਰ ਇੱਕ ਹੋਰ ਸਵਾਲ ਤੋਂ ਬਾਅਦ ਪੈਦਾ ਹੋਇਆ: "DevOps ਕੌਣ ਹੈ?" ਇਹ ਕੀ ਹੈ ਜਾਂ ਕੌਣ ਹੈ ਲਈ ਅਜੇ ਵੀ ਕੋਈ ਸਥਾਪਿਤ ਮਿਆਦ ਨਹੀਂ ਹੈ। ਇਸ ਵਿੱਚ ਕੁਝ ਜਵਾਬ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹਨ видео. ਪਹਿਲਾਂ, ਮੈਂ ਇਸ ਵਿੱਚੋਂ ਮੁੱਖ ਨੁਕਤੇ ਉਜਾਗਰ ਕਰਾਂਗਾ, ਅਤੇ ਫਿਰ ਮੈਂ ਆਪਣੇ ਨਿਰੀਖਣ ਅਤੇ ਵਿਚਾਰ ਸਾਂਝੇ ਕਰਾਂਗਾ।

DevOps ਇੱਕ ਮਾਹਰ ਨਹੀਂ ਹੈ ਜਿਸਨੂੰ ਕਿਰਾਏ 'ਤੇ ਲਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਨਾ ਕਿ ਉਪਯੋਗਤਾਵਾਂ ਦਾ ਇੱਕ ਸਮੂਹ, ਅਤੇ ਨਾ ਕਿ ਇੰਜੀਨੀਅਰਾਂ ਵਾਲੇ ਡਿਵੈਲਪਰਾਂ ਦਾ ਵਿਭਾਗ।

DevOps ਇੱਕ ਦਰਸ਼ਨ ਅਤੇ ਕਾਰਜਪ੍ਰਣਾਲੀ ਹੈ।

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

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

DevOps ਦੇ ਟੀਚਿਆਂ ਨੂੰ ਤਿੰਨ ਬਿੰਦੂਆਂ ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

• ਸਾਫਟਵੇਅਰ ਨੂੰ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਅਪਡੇਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
• ਸਾਫਟਵੇਅਰ ਨੂੰ ਜਲਦੀ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ.
• ਸੌਫਟਵੇਅਰ ਨੂੰ ਸੁਵਿਧਾਜਨਕ ਅਤੇ ਥੋੜੇ ਸਮੇਂ ਵਿੱਚ ਤੈਨਾਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ.

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

ਅਤੇ ਇਹ DevOps ਟੂਲਸ ਦਾ ਸਿਰਫ ਹਿੱਸਾ ਹੈ

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

ਇੰਟਰਵਿਊ ਦੇ ਤਜਰਬੇ ਤੋਂ, ਮੈਂ ਹੇਠਾਂ ਦਿੱਤੀ ਤਸਵੀਰ ਦੇਖਦਾ ਹਾਂ: ਉਹ ਮਾਹਰ ਜੋ DevOps ਨੂੰ ਨੌਕਰੀ ਦਾ ਸਿਰਲੇਖ ਮੰਨਦੇ ਹਨ ਉਹਨਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਸਹਿਕਰਮੀਆਂ ਨਾਲ ਗਲਤਫਹਿਮੀ ਹੁੰਦੀ ਹੈ.

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

ਫਿਰ ਮੈਂ ਉਸਨੂੰ ਇੱਕ ਸਵਾਲ ਪੁੱਛਿਆ ਜੋ ਹਰ ਉਮੀਦਵਾਰ ਲਈ ਮੇਰੀ ਸੂਚੀ ਵਿੱਚ ਉੱਚਾ ਹੈ।

— DevOps ਦਾ ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਲਈ ਕੀ ਅਰਥ ਹੈ?
- ਆਮ ਤੌਰ 'ਤੇ ਜਾਂ ਮੈਂ ਇਸਨੂੰ ਕਿਵੇਂ ਸਮਝਦਾ ਹਾਂ?

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

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

DevOps ਕਾਰਜਪ੍ਰਣਾਲੀ ਅਤੇ ਦਰਸ਼ਨ

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

DevOps ਕਾਰਜਪ੍ਰਣਾਲੀ ਟੀਚਿਆਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਇੱਕ ਸਾਧਨ ਹੈ।

ਹੁਣ ਇਸ ਬਾਰੇ ਕਿ DevOps ਫ਼ਲਸਫ਼ਾ ਕੀ ਹੈ। ਅਤੇ ਇਹ ਸ਼ਾਇਦ ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਸਵਾਲ ਹੈ.

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

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

ਆਪਣੇ ਅਨੁਭਵ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਮੈਂ ਇਸ ਫਲਸਫੇ ਦੇ ਕੁਝ "ਅਨੁਮਾਨਾਂ" ਨੂੰ ਰਸਮੀ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ। ਨਤੀਜਾ ਇਹ ਹੈ:

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

ਮੈਂ ਸੋਚਦਾ ਹਾਂ ਕਿ ਮੇਰੇ "ਅਨੁਮਾਨ" ਚਰਚਾ ਲਈ ਇੱਕ ਵੱਖਰਾ ਵਿਸ਼ਾ ਹਨ। ਪਰ ਹੁਣ ਬਣਾਉਣ ਲਈ ਕੁਝ ਹੈ.

DevOps ਕੀ ਕਰਦਾ ਹੈ

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

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

ਰੂਸ ਵਿੱਚ, DevOps ਅਜੇ ਵੀ ਇੱਕ ਬਹੁਤ ਹੀ ਨੌਜਵਾਨ ਹੈ, ਪਰ ਪਹਿਲਾਂ ਹੀ ਰੁਝਾਨ ਵਾਲਾ ਵਿਸ਼ਾ ਹੈ। ਜਿੱਥੋਂ ਤੱਕ ਮੈਨੂੰ ਪਤਾ ਹੈ, ਇਕੱਲੇ ਮਾਸਕੋ ਵਿੱਚ 2019 ਵਿੱਚ ਅਜਿਹੇ ਮਾਹਰਾਂ ਦੀ ਘਾਟ 1000 ਤੋਂ ਵੱਧ ਲੋਕਾਂ ਦੀ ਸੀ। ਅਤੇ ਮਾਲਕਾਂ ਲਈ ਕੁਬਰਨੇਟਸ ਸ਼ਬਦ ਲਗਭਗ ਇੱਕ ਬਲਦ ਲਈ ਲਾਲ ਰਾਗ ਵਰਗਾ ਹੈ। ਇਸ ਸਾਧਨ ਦੇ ਅਨੁਯਾਈ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਤਿਆਰ ਹਨ ਭਾਵੇਂ ਇਹ ਜ਼ਰੂਰੀ ਨਾ ਹੋਵੇ ਅਤੇ ਆਰਥਿਕ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੋਵੇ. ਰੁਜ਼ਗਾਰਦਾਤਾ ਹਮੇਸ਼ਾ ਇਹ ਨਹੀਂ ਸਮਝਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਵਰਤੋਂ ਕਰਨਾ ਵਧੇਰੇ ਉਚਿਤ ਹੈ, ਅਤੇ ਉਚਿਤ ਤੈਨਾਤੀ ਦੇ ਨਾਲ, ਇੱਕ ਰਵਾਇਤੀ ਕਲੱਸਟਰ ਸਕੀਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਨਾਲੋਂ ਇੱਕ Kubernetes ਕਲੱਸਟਰ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਦੀ ਲਾਗਤ 2-3 ਗੁਣਾ ਵੱਧ ਹੈ। ਇਸਦੀ ਵਰਤੋਂ ਕਰੋ ਜਿੱਥੇ ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਇਸਦੀ ਲੋੜ ਹੈ।

ਪੈਸੇ ਦੇ ਮਾਮਲੇ ਵਿੱਚ DevOps ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਮਹਿੰਗਾ ਹੈ। ਅਤੇ ਇਹ ਸਿਰਫ ਉੱਥੇ ਜਾਇਜ਼ ਹੈ ਜਿੱਥੇ ਇਹ ਦੂਜੇ ਖੇਤਰਾਂ ਵਿੱਚ ਆਰਥਿਕ ਲਾਭ ਲਿਆਉਂਦਾ ਹੈ, ਨਾ ਕਿ ਆਪਣੇ ਆਪ 'ਤੇ।

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

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

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

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

ਜਦੋਂ DevOps ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ

ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ DevOps ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ। ਇਹ ਇੱਕ ਤੱਥ ਹੈ - ਇਸਨੂੰ ਸਮਝਣ ਅਤੇ ਸਵੀਕਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

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

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

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

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

• DevOops
• DevOpsConf
• ਹਾਈਲੋਡ++
• ਫਲੈਂਟ
• ਮੇਲਰੂ ਕਲਾਉਡ ਹੱਲ

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

ਜੇ ਤੁਹਾਡੀ ਕੰਪਨੀ ਇੱਕ ਛੋਟੇ ਸਟੋਰ ਵਿੱਚ ਮੱਛੀ ਵੇਚਦੀ ਹੈ ਅਤੇ ਸਿਰਫ IT ਉਤਪਾਦ ਦੋ 1C ਹੈ: ਐਂਟਰਪ੍ਰਾਈਜ਼ ਕੌਂਫਿਗਰੇਸ਼ਨ (ਲੇਖਾ ਅਤੇ UNF), ਤਾਂ ਇਹ DevOps ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਮੁਸ਼ਕਿਲ ਹੈ।

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

ਸਾਲਾਨਾ ਵਿੱਤੀ ਟਰਨਓਵਰ ਦਾ ਆਕਾਰ ਅਤੇ ਮਾਤਰਾ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਮੁੱਖ ਮਾਪਦੰਡ ਨਹੀਂ ਹੈ ਕਿ ਕੀ ਤੁਹਾਡੀ ਕੰਪਨੀ ਨੂੰ DevOps ਦੀ ਲੋੜ ਹੈ।

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

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

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

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

ਇਹ ਸਮਝਣ ਲਈ ਮੁੱਖ ਮਾਪਦੰਡ ਕਿ ਕੀ DevOps ਦੀ ਲੋੜ ਹੈ: ਕੰਪਨੀ ਅਤੇ ਗਾਹਕਾਂ ਲਈ ਤੁਹਾਡੇ IT ਉਤਪਾਦਾਂ ਦਾ ਕੀ ਮੁੱਲ ਹੈ।

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

ਕੋਈ ਵੀ ਗੇਮ ਫੰਡਿੰਗ ਦੇ ਕਾਰਨ ਮੌਜੂਦ ਹੈ: ਖਿਡਾਰੀਆਂ ਤੋਂ ਸਿੱਧੇ ਜਾਂ ਅਸਿੱਧੇ। ਪਲੇਜੈਂਡਰੀ 'ਤੇ, ਅਸੀਂ 200 ਤੋਂ ਵੱਧ ਲੋਕਾਂ ਦੇ ਨਾਲ ਮੁਫਤ ਮੋਬਾਈਲ ਗੇਮਾਂ ਵਿਕਸਿਤ ਕਰਦੇ ਹਾਂ ਜੋ ਉਹਨਾਂ ਦੀ ਰਚਨਾ ਵਿੱਚ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਅਸੀਂ DevOps ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰੀਏ?

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

ਅਸੀਂ ਹੁਣ ਏਕਤਾ ਦੇ ਨਾਲ ਸਾਰੀਆਂ ਅਸੈਂਬਲੀ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਚਲਾਉਣ ਅਤੇ ਐਪ ਸਟੋਰ ਅਤੇ ਪਲੇ ਮਾਰਕਿਟ ਵਿੱਚ ਤੈਨਾਤ ਕਰਨ ਲਈ ਜੈਨਕਿਨਸ ਨੂੰ ਇੱਕ CI/CD ਪਾਈਪਲਾਈਨ ਟੂਲ ਵਜੋਂ ਸਰਗਰਮੀ ਨਾਲ ਵਰਤ ਰਹੇ ਹਾਂ। ਕਲਾਸਿਕ ਟੂਲਕਿੱਟ ਤੋਂ ਹੋਰ:

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

ਸਾਡੀਆਂ ਤੁਰੰਤ ਯੋਜਨਾਵਾਂ ਵਿੱਚ SonarQube ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸਥਿਰ ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਪੇਸ਼ ਕਰਨਾ ਅਤੇ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਪੜਾਅ 'ਤੇ ਸੇਲੇਨਿਅਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸਵੈਚਲਿਤ UI ਟੈਸਟਿੰਗ ਕਰਨਾ ਸ਼ਾਮਲ ਹੈ।

ਸੰਪੂਰਨ ਹੋਣ ਦੇ ਬਜਾਏ

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

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

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

ਸਰੋਤ: www.habr.com