ਹਫੜਾ-ਦਫੜੀ ਦਾ ਪ੍ਰਬੰਧਨ: ਤਕਨੀਕੀ ਨਕਸ਼ੇ ਦੀ ਮਦਦ ਨਾਲ ਚੀਜ਼ਾਂ ਨੂੰ ਕ੍ਰਮਬੱਧ ਕਰਨਾ

ਤਸਵੀਰ: Unsplash

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

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

Chaos ਅਤੇ DevOps ਬਾਰੇ

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

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

ਵਿਲੱਖਣਤਾ ਅਤੇ ਲੜੀਵਾਰ ਹੱਲਾਂ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਕਿਵੇਂ ਲੱਭਣਾ ਹੈ?

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

ਵਿਕਾਸ ਨਿਰਦੇਸ਼ਕ: "ਮੁੰਡੇ, ਕੀ ਅਸੀਂ ਕਿਸੇ ਤਰ੍ਹਾਂ ਇਹ ਮੁਲਾਂਕਣ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ DevOps ਉਤਪਾਦਾਂ ਲਈ ਕੀ ਕਰਦਾ ਹੈ?"

ਸਾਨੂੰ: "ਅਸੀਂ ਨਹੀਂ ਜਾਣਦੇ, ਅਸੀਂ ਅਜਿਹਾ ਸਵਾਲ ਨਹੀਂ ਪੁੱਛਿਆ, ਪਰ ਕਿਹੜੇ ਸੰਕੇਤਾਂ 'ਤੇ ਵਿਚਾਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ?"

ਵਿਕਾਸ ਨਿਰਦੇਸ਼ਕ: "ਕੌਣ ਜਾਣਦਾ ਹੈ! ਸੋਚੋ…”

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

ਇਸ ਲਈ, ਤੁਸੀਂ 10 ਤੋਂ 200 ਲੋਕਾਂ ਦੀਆਂ ਕਾਫ਼ੀ ਵੱਡੀਆਂ ਟੀਮਾਂ ਦੇ ਨਾਲ ਇੱਕ ਦਰਜਨ ਉਤਪਾਦਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਿਵੇਂ ਕਰਦੇ ਹੋ ਅਤੇ ਹੱਲਾਂ ਦੀ ਨਕਲ ਕਰਦੇ ਸਮੇਂ ਮਾਪਣਯੋਗ ਮੈਟ੍ਰਿਕਸ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋ?

1:0 ਮੋਢੇ ਦੇ ਬਲੇਡ 'ਤੇ Chaos, ਜਾਂ DevOps ਦੇ ਹੱਕ ਵਿੱਚ

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

ਆਮ ਉਤਪਾਦਨ ਕਾਰਜ

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

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

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

ਚਿੱਤਰ 'ਤੇ ਕਲਿੱਕ ਕਰਨ ਨਾਲ ਇਹ ਪੂਰੇ ਆਕਾਰ ਵਿਚ ਖੁੱਲ੍ਹ ਜਾਵੇਗਾ।

ਕੰਪਨੀ ਵਿੱਚ ਸਾਡੇ ਕੰਮ ਨੂੰ ਕਈ ਕਾਰਜਸ਼ੀਲ ਖੇਤਰਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ। ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਦਿਸ਼ਾ ਵਿਭਾਗ ਦੇ ਸਾਰੇ "ਲੋਹੇ" ਸਰੋਤਾਂ ਦੇ ਸੰਚਾਲਨ ਦੇ ਅਨੁਕੂਲਤਾ ਵਿੱਚ ਰੁੱਝੀ ਹੋਈ ਹੈ, ਨਾਲ ਹੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਦੀ ਤੈਨਾਤੀ ਅਤੇ ਉਹਨਾਂ 'ਤੇ ਵਾਤਾਵਰਣ ਦੀ ਸਵੈਚਾਲਨ. ਨਿਗਰਾਨੀ ਦੀ ਦਿਸ਼ਾ 24/7 ਸੇਵਾ ਪ੍ਰਦਰਸ਼ਨ ਨਿਯੰਤਰਣ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ; ਅਸੀਂ ਡਿਵੈਲਪਰਾਂ ਲਈ ਇੱਕ ਸੇਵਾ ਵਜੋਂ ਨਿਗਰਾਨੀ ਵੀ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਾਂ। ਵਰਕਫਲੋ ਦਿਸ਼ਾ ਟੀਮਾਂ ਨੂੰ ਵਿਕਾਸ ਅਤੇ ਜਾਂਚ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ, ਕੋਡ ਦੀ ਸਥਿਤੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਅਤੇ ਪ੍ਰੋਜੈਕਟਾਂ 'ਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਟੂਲ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ। ਅਤੇ ਅੰਤ ਵਿੱਚ, ਵੈਬਦੇਵ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ GUS ਅਤੇ FLUS ਅੱਪਡੇਟ ਸਰਵਰਾਂ 'ਤੇ ਰੀਲੀਜ਼ਾਂ ਦੇ ਪ੍ਰਕਾਸ਼ਨ ਦੇ ਨਾਲ-ਨਾਲ LicenseLab ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਉਤਪਾਦਾਂ ਦਾ ਲਾਇਸੈਂਸ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਉਤਪਾਦਨ ਪਾਈਪਲਾਈਨ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ, ਅਸੀਂ ਡਿਵੈਲਪਰਾਂ ਲਈ ਬਹੁਤ ਸਾਰੀਆਂ ਵੱਖ-ਵੱਖ ਸਹਾਇਤਾ ਸੇਵਾਵਾਂ ਸਥਾਪਤ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਕਰਦੇ ਹਾਂ (ਤੁਸੀਂ ਪੁਰਾਣੇ ਮੁਲਾਕਾਤਾਂ 'ਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਬਾਰੇ ਕਹਾਣੀਆਂ ਸੁਣ ਸਕਦੇ ਹੋ: ਓਪ!ਡਿਵੋਪਸ! 2016 и ਓਪ!ਡਿਵੋਪਸ! 2017). ਅਸੀਂ ਅੰਦਰੂਨੀ ਆਟੋਮੇਸ਼ਨ ਟੂਲ ਵੀ ਵਿਕਸਿਤ ਕਰਦੇ ਹਾਂ, ਸਮੇਤ ਓਪਨ ਸੋਰਸ ਹੱਲ.

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

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

ਤੁਸੀਂ ਹੈਬਰੇ 'ਤੇ ਸਾਡੇ ਹੋਰ ਲੇਖਾਂ ਵਿੱਚ ਆਮ DevOps ਕਾਰਜਾਂ ਬਾਰੇ ਪੜ੍ਹ ਸਕਦੇ ਹੋ: "ਨਿੱਜੀ ਅਨੁਭਵ: ਸਾਡੀ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਪ੍ਰਣਾਲੀ ਕਿਹੋ ਜਿਹੀ ਦਿਖਦੀ ਹੈ"ਅਤੇ"ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਸਵੈਚਾਲਨ: ਅਸੀਂ ਸਕਾਰਾਤਮਕ ਤਕਨਾਲੋਜੀਆਂ 'ਤੇ DevOps ਵਿਚਾਰਾਂ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ".

ਕਈ ਆਮ ਉਤਪਾਦਨ ਚੇਨ ਬਣਦੇ ਹਨ ਨਿਰਮਾਣ ਪ੍ਰਕਿਰਿਆ. ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਵਰਣਨ ਕਰਨ ਲਈ ਮਿਆਰੀ ਪਹੁੰਚ ਕਾਰਜਸ਼ੀਲ IDEF0 ਮਾਡਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ।

ਇੱਕ ਨਿਰਮਾਣ ਸੀਆਈ ਪ੍ਰਕਿਰਿਆ ਦੇ ਮਾਡਲਿੰਗ ਦੀ ਇੱਕ ਉਦਾਹਰਣ

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

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

ਜੇਕਰ ਅਸੀਂ ਆਪਣੀ ਰੀਲੀਜ਼ ਸਕੀਮ ਨੂੰ ਬਹੁਤ ਸਰਲ ਅਤੇ ਸਧਾਰਨ ਬਣਾਉਂਦੇ ਹਾਂ, ਤਾਂ ਇਸ ਵਿੱਚ ਹੇਠਾਂ ਦਿੱਤੇ ਕਦਮ ਸ਼ਾਮਲ ਹਨ:

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

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

ਚਿੱਤਰ 'ਤੇ ਕਲਿੱਕ ਕਰਨ ਨਾਲ ਇਹ ਪੂਰੇ ਆਕਾਰ ਵਿਚ ਖੁੱਲ੍ਹ ਜਾਵੇਗਾ।

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

ਉਮੀਦ ਦਾ ਜਨਮ

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

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

ਨਕਸ਼ੇ ਦੀਆਂ ਕਤਾਰਾਂ ਅਤੇ ਕਾਲਮਾਂ ਦੇ ਚੌਰਾਹੇ 'ਤੇ, ਅਸੀਂ ਇੱਕ ਖਾਸ ਪੜਾਅ ਅਤੇ ਉਤਪਾਦ ਲਈ ਸਥਿਤੀਆਂ ਨੂੰ ਹੇਠਾਂ ਰੱਖਦੇ ਹਾਂ। ਸਥਿਤੀਆਂ ਲਈ, ਰਾਜਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਸੀ:

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

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

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

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

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

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

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

ਉਤਪਾਦਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਤਕਨੀਕੀ ਨਕਸ਼ਾ

ਜੇਕਰ ਅਸੀਂ ਆਪਣੇ ਸਾਰੇ ਪੜਾਵਾਂ ਅਤੇ ਕਦਮਾਂ ਨੂੰ ਲੈਂਦੇ ਹਾਂ, ਉਹਨਾਂ ਨੂੰ ਟੈਗਸ ਨਾਲ ਏਨਕੋਡ ਕਰਦੇ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਲੜੀ ਵਿੱਚ ਫੈਲਾਉਂਦੇ ਹਾਂ, ਤਾਂ ਇਹ ਬਹੁਤ ਲੰਬਾ ਅਤੇ ਸਮਝ ਤੋਂ ਬਾਹਰ ਹੋ ਜਾਵੇਗਾ (ਸਿਰਫ਼ ਬਹੁਤ ਹੀ "ਪਾਇਥਨ ਪੂਛ" ਜਿਸ ਬਾਰੇ ਅਸੀਂ ਲੇਖ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਗੱਲ ਕੀਤੀ ਸੀ) :

[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]

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

ਉਹਨਾਂ ਤੋਂ ਇਲਾਵਾ, ਵੱਖਰੇ ਪੜਾਵਾਂ ਨੂੰ ਵੱਖ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਸਥਿਤੀ ਦੀ ਨਿਗਰਾਨੀ [InfMonitoring], ਸਰੋਤ ਕੋਡ ਸੰਸਕਰਣ [SourceCodeControl], ਵਾਤਾਵਰਣ ਦੀ ਤਿਆਰੀ [ਤਿਆਰ ਕਰੋ], ਪ੍ਰੋਜੈਕਟ ਪ੍ਰਬੰਧਨ [ਵਰਕਫਲੋ], ਟੀਮਾਂ ਨੂੰ ਸੰਚਾਰ ਸਾਧਨ ਪ੍ਰਦਾਨ ਕਰਨਾ [ਸੰਚਾਰ], ਉਤਪਾਦ ਪ੍ਰਮਾਣੀਕਰਣ [ ਪ੍ਰਮਾਣੀਕਰਣ] ਅਤੇ CI ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਸਵੈ-ਨਿਰਭਰਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ [CISelfSufficiency] (ਉਦਾਹਰਨ ਲਈ, ਇੰਟਰਨੈਟ ਤੋਂ ਅਸੈਂਬਲੀਆਂ ਦੀ ਸੁਤੰਤਰਤਾ)। ਸਾਡੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ ਦਰਜਨਾਂ ਕਦਮਾਂ 'ਤੇ ਵੀ ਵਿਚਾਰ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ, ਕਿਉਂਕਿ ਉਹ ਬਹੁਤ ਖਾਸ ਹਨ।

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

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

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

ਚਿੱਤਰ 'ਤੇ ਕਲਿੱਕ ਕਰਨ ਨਾਲ ਇਹ ਪੂਰੇ ਆਕਾਰ ਵਿਚ ਖੁੱਲ੍ਹ ਜਾਵੇਗਾ।

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

ਸਾਡੇ ਸੜਕ ਦੇ ਨਕਸ਼ੇ ਦੀ ਬਣਤਰ

ਨਕਸ਼ੇ ਵਿੱਚ ਕਈ ਭਾਗ ਹੁੰਦੇ ਹਨ:

1. ਸਿਰਲੇਖ ਖੇਤਰ - ਇੱਥੇ ਨਕਸ਼ੇ ਦਾ ਇੱਕ ਆਮ ਵਰਣਨ ਹੈ, ਬੁਨਿਆਦੀ ਧਾਰਨਾਵਾਂ ਪੇਸ਼ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ, ਮੁੱਖ ਸਰੋਤ ਅਤੇ ਉਤਪਾਦਨ ਪ੍ਰਕਿਰਿਆ ਦੇ ਨਤੀਜੇ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੇ ਗਏ ਹਨ।
2. ਡੈਸ਼ਬੋਰਡ - ਇੱਥੇ ਤੁਸੀਂ ਵਿਅਕਤੀਗਤ ਉਤਪਾਦਾਂ ਲਈ ਡੇਟਾ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰ ਸਕਦੇ ਹੋ, ਲਾਗੂ ਕੀਤੇ ਪੜਾਵਾਂ ਦਾ ਸੰਖੇਪ ਅਤੇ ਸਾਰੇ ਉਤਪਾਦਾਂ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਕਦਮ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਹਨ।
3. ਟੈਕਨੋਲੋਜੀਕਲ ਮੈਪ - ਤਕਨੀਕੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਇੱਕ ਸਾਰਣੀ ਵਿੱਚ ਵੇਰਵਾ। ਨਕਸ਼ੇ 'ਤੇ:
   • ਸਾਰੇ ਪੜਾਅ, ਕਦਮ ਅਤੇ ਉਹਨਾਂ ਦੇ ਕੋਡ ਦਿੱਤੇ ਗਏ ਹਨ;
   • ਪੜਾਵਾਂ ਦਾ ਛੋਟਾ ਅਤੇ ਪੂਰਾ ਵੇਰਵਾ ਦਿੱਤਾ ਗਿਆ ਹੈ;
   • ਹਰੇਕ ਪੜਾਅ 'ਤੇ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਇਨਪੁਟ ਸਰੋਤ ਅਤੇ ਸੇਵਾਵਾਂ ਦਰਸਾਏ ਗਏ ਹਨ;
   • ਹਰੇਕ ਪੜਾਅ ਦੇ ਨਤੀਜੇ ਅਤੇ ਇੱਕ ਵੱਖਰੇ ਕਦਮ ਦਰਸਾਏ ਗਏ ਹਨ;
   • ਹਰੇਕ ਪੜਾਅ ਅਤੇ ਕਦਮ ਲਈ ਜ਼ਿੰਮੇਵਾਰੀ ਦਾ ਖੇਤਰ ਦਰਸਾਇਆ ਗਿਆ ਹੈ;
   • ਤਕਨੀਕੀ ਸਰੋਤ, ਜਿਵੇਂ ਕਿ HDD (SSD), RAM, vCPU, ਅਤੇ ਇਸ ਪੜਾਅ 'ਤੇ ਕੰਮ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ ਮੈਨ-ਘੰਟੇ, ਮੌਜੂਦਾ ਸਮੇਂ ਦੋਵਾਂ ਵਿੱਚ - ਇੱਕ ਤੱਥ, ਅਤੇ ਭਵਿੱਖ ਵਿੱਚ - ਇੱਕ ਯੋਜਨਾ, ਨਿਰਧਾਰਤ ਕੀਤੀ ਗਈ ਹੈ;
   • ਹਰੇਕ ਉਤਪਾਦ ਲਈ, ਇਹ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ ਕਿ ਇਸਦੇ ਲਈ ਕਿਹੜੇ ਤਕਨੀਕੀ ਪੜਾਵਾਂ ਜਾਂ ਕਦਮਾਂ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ, ਲਾਗੂ ਕਰਨ ਲਈ ਯੋਜਨਾਬੱਧ, ਅਪ੍ਰਸੰਗਿਕ ਜਾਂ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ।

ਤਕਨੀਕੀ ਨਕਸ਼ੇ ਦੇ ਆਧਾਰ 'ਤੇ ਫੈਸਲਾ ਲੈਣਾ

ਨਕਸ਼ੇ ਦੀ ਜਾਂਚ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਕੁਝ ਕਾਰਵਾਈਆਂ ਕਰਨਾ ਸੰਭਵ ਹੈ - ਕੰਪਨੀ ਵਿੱਚ ਕਰਮਚਾਰੀ ਦੀ ਭੂਮਿਕਾ (ਵਿਕਾਸ ਪ੍ਰਬੰਧਕ, ਉਤਪਾਦ ਪ੍ਰਬੰਧਕ, ਵਿਕਾਸਕਾਰ ਜਾਂ ਟੈਸਟਰ) 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ:

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

ਉਪਰੋਕਤ ਸਾਰੇ ਦਾ ਸੰਖੇਪ

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

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

ਨਤੀਜੇ

ਲੇਖ ਕਾਫ਼ੀ ਲੰਬਾ ਨਿਕਲਿਆ, ਪਰ ਗੁੰਝਲਦਾਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਮਾਡਲਿੰਗ ਦਾ ਵਰਣਨ ਕਰਦੇ ਸਮੇਂ ਇਹ ਲਾਜ਼ਮੀ ਹੈ. ਅੰਤ ਵਿੱਚ, ਮੈਂ ਆਪਣੇ ਮੁੱਖ ਵਿਚਾਰਾਂ ਨੂੰ ਸੰਖੇਪ ਵਿੱਚ ਠੀਕ ਕਰਨਾ ਚਾਹਾਂਗਾ:

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

ਅਗਲੇ ਲੇਖਾਂ ਵਿੱਚ, ਅਸੀਂ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਵਰਣਨ ਕਰਾਂਗੇ ਕਿ ਸਾਡੇ ਨਕਸ਼ੇ 'ਤੇ ਕੁਝ ਤਕਨੀਕੀ ਪੜਾਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਕਿਹੜੇ ਤਕਨੀਕੀ ਸਾਧਨ ਵਰਤੇ ਜਾਂਦੇ ਹਨ।

ਲੇਖ ਲੇਖਕ:

• ਅਲੈਗਜ਼ੈਂਡਰ ਪੈਜ਼ਡਨੀਕੋਵ - ਸਕਾਰਾਤਮਕ ਤਕਨਾਲੋਜੀਆਂ 'ਤੇ ਆਟੋਮੇਸ਼ਨ (DevOps) ਦੇ ਮੁਖੀ
• ਤੈਮੂਰ ਗਿਲਮੁਲਿਨ - ਡਿਪਟੀ ਸਕਾਰਾਤਮਕ ਤਕਨਾਲੋਜੀ 'ਤੇ ਆਟੋਮੇਸ਼ਨ ਵਿਭਾਗ (DevOps) ਦੇ ਮੁਖੀ

ਸਰੋਤ: www.habr.com