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

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

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

ਅਸੀਂ ਕੌਣ ਹਾਂ, ਅਸੀਂ ਕਿੱਥੇ ਹਾਂ ਅਤੇ ਸਾਨੂੰ ਕਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ

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

• ਸਾਡੇ ਕੋਲ ਫਾਇਦਿਆਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ: ਇੱਕ ਖਾਸ ਪਿਛੋਕੜ, ਅਭਿਆਸਾਂ ਦਾ ਗਿਆਨ, ਕੋਡ ਲਿਖਣ ਦੀ ਯੋਗਤਾ, ਨਵੀਆਂ ਚੀਜ਼ਾਂ ਸਿੱਖਣ ਦੀ ਇੱਛਾ।
• ਅਤੇ ਇੱਕ ਝੁਲਸਣ ਵਾਲਾ ਹਿੱਸਾ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਘਟਾਓ ਵੀ ਹੈ: ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਹਾਰਡਵੇਅਰ ਬਾਰੇ ਗਿਆਨ ਦੀ ਘਾਟ.

ਤਕਨਾਲੋਜੀ ਸਟੈਕ ਜੋ ਅਸੀਂ ਆਪਣੇ IaC ਵਿੱਚ ਵਰਤਦੇ ਹਾਂ।

• ਸਰੋਤ ਬਣਾਉਣ ਲਈ ਟੈਰਾਫਾਰਮ।
• ਚਿੱਤਰ ਇਕੱਠੇ ਕਰਨ ਲਈ ਪੈਕਰ. ਇਹ ਵਿੰਡੋਜ਼, CentOS 7 ਚਿੱਤਰ ਹਨ।
• Jsonnet drone.io ਵਿੱਚ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਬਿਲਡ ਬਣਾਉਣ ਦੇ ਨਾਲ-ਨਾਲ ਪੈਕਰ json ਅਤੇ ਸਾਡੇ ਟੈਰਾਫਾਰਮ ਮੋਡੀਊਲ ਬਣਾਉਣ ਲਈ।
• Azure.
• ਚਿੱਤਰ ਤਿਆਰ ਕਰਨ ਵੇਲੇ ਜਵਾਬਦੇਹ।
• ਸਹਾਇਕ ਸੇਵਾਵਾਂ ਅਤੇ ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ ਸਕ੍ਰਿਪਟਾਂ ਲਈ ਪਾਈਥਨ।
• ਅਤੇ ਇਹ ਸਭ VSCode ਵਿੱਚ ਪਲੱਗਇਨ ਨਾਲ ਟੀਮ ਦੇ ਮੈਂਬਰਾਂ ਵਿਚਕਾਰ ਸਾਂਝੇ ਕੀਤੇ ਗਏ ਹਨ।

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

ਅਸੀਂ ਵਰਤਮਾਨ ਵਿੱਚ ਹੇਠਾਂ ਦਿੱਤੇ IaC ਮੁੱਦਿਆਂ ਨਾਲ ਸੰਘਰਸ਼ ਕਰ ਰਹੇ ਹਾਂ:

• ਕੋਡ ਵਿਕਾਸ ਲਈ ਸਾਧਨਾਂ ਅਤੇ ਸਾਧਨਾਂ ਦੀ ਅਪੂਰਣਤਾ।
• ਹੌਲੀ ਤੈਨਾਤੀ। ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਅਸਲ ਸੰਸਾਰ ਦਾ ਹਿੱਸਾ ਹੈ, ਅਤੇ ਇਹ ਹੌਲੀ ਹੋ ਸਕਦਾ ਹੈ।
• ਪਹੁੰਚ ਅਤੇ ਅਭਿਆਸ ਦੀ ਘਾਟ.
• ਅਸੀਂ ਨਵੇਂ ਹਾਂ ਅਤੇ ਬਹੁਤ ਕੁਝ ਨਹੀਂ ਜਾਣਦੇ।

ਬਚਾਅ ਲਈ ਐਕਸਟ੍ਰੀਮ ਪ੍ਰੋਗਰਾਮਿੰਗ (XP)

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

ਤੁਹਾਡੇ ਉਦਯੋਗ ਲਈ XP ਪਹੁੰਚ ਦੀ ਲਾਗੂ ਹੋਣ ਦੀ ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੈਇੱਥੇ ਵਾਤਾਵਰਣ ਦਾ ਵਰਣਨ ਹੈ ਜਿਸ ਲਈ XP ਚੰਗੀ ਤਰ੍ਹਾਂ ਅਨੁਕੂਲ ਹੈ, ਅਤੇ ਇਹ ਸਾਡੇ ਨਾਲ ਕਿਵੇਂ ਸੰਬੰਧਿਤ ਹੈ:

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

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

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

ਆਉ ਕੁਝ XP ਅਭਿਆਸਾਂ ਨੂੰ ਵੇਖੀਏ ਅਤੇ ਉਹ ਫੀਡਬੈਕ ਦੀ ਗਤੀ ਅਤੇ ਗੁਣਵੱਤਾ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਤ ਕਰਦੇ ਹਨ।

XP ਫੀਡਬੈਕ ਲੂਪ ਸਿਧਾਂਤ

ਮੇਰੀ ਸਮਝ ਵਿੱਚ, ਫੀਡਬੈਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਹੈ, ਕੀ ਮੈਂ ਸਹੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹਾਂ, ਕੀ ਅਸੀਂ ਉੱਥੇ ਜਾ ਰਹੇ ਹਾਂ? XP ਕੋਲ ਇਸਦੇ ਲਈ ਇੱਕ ਬ੍ਰਹਮ ਸਕੀਮ ਹੈ: ਇੱਕ ਸਮਾਂ ਫੀਡਬੈਕ ਲੂਪ। ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਜਿੰਨੇ ਨੀਵੇਂ ਹਾਂ, ਓਨੀ ਤੇਜ਼ੀ ਨਾਲ ਅਸੀਂ ਜ਼ਰੂਰੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਲਈ ਓ.ਐਸ.

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

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

ਮਹੱਤਵਪੂਰਨ: ਫੀਡਬੈਕ ਉੱਪਰ ਦੱਸੀਆਂ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਹੱਲ ਹੋ ਸਕਦਾ ਹੈ। XP ਅਭਿਆਸਾਂ ਦੇ ਨਾਲ ਮਿਲ ਕੇ, ਇਹ ਤੁਹਾਨੂੰ ਨਿਰਾਸ਼ਾ ਦੇ ਅਥਾਹ ਖੱਡ ਵਿੱਚੋਂ ਬਾਹਰ ਕੱਢ ਸਕਦਾ ਹੈ।

ਆਪਣੇ ਆਪ ਨੂੰ ਨਿਰਾਸ਼ਾ ਦੇ ਅਥਾਹ ਕੁੰਡ ਵਿੱਚੋਂ ਕਿਵੇਂ ਕੱਢਣਾ ਹੈ: ਤਿੰਨ ਅਭਿਆਸ

ਟੈਸਟ

XP ਫੀਡਬੈਕ ਲੂਪ ਵਿੱਚ ਟੈਸਟਾਂ ਦਾ ਦੋ ਵਾਰ ਜ਼ਿਕਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਅਜਿਹਾ ਹੀ ਨਹੀਂ ਹੈ। ਉਹ ਪੂਰੀ ਐਕਸਟ੍ਰੀਮ ਪ੍ਰੋਗਰਾਮਿੰਗ ਤਕਨੀਕ ਲਈ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹਨ.

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

ਇੱਕ ਕਲਾਸਿਕ ਟੈਸਟਿੰਗ ਪਿਰਾਮਿਡ ਹੈ, ਜੋ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਹੋਰ ਟੈਸਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ.

ਇਹ ਢਾਂਚਾ IaC ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਸਾਡੇ 'ਤੇ ਕਿਵੇਂ ਲਾਗੂ ਹੁੰਦਾ ਹੈ? ਅਸਲ ਵਿੱਚ... ਬਿਲਕੁਲ ਨਹੀਂ।

• ਯੂਨਿਟ ਟੈਸਟ, ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਉਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਹੀਂ ਹੋ ਸਕਦੇ। ਜਾਂ ਉਹ ਬਹੁਤ ਅਸਿੱਧੇ ਤੌਰ 'ਤੇ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਜਾਂਚ ਕਰ ਰਹੇ ਹਨ. ਵਾਸਤਵ ਵਿੱਚ, ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਬਿਲਕੁਲ ਨਹੀਂ ਲਿਖਦੇ. ਪਰ ਇੱਥੇ ਅਜਿਹੇ ਟੈਸਟਾਂ ਲਈ ਕੁਝ ਐਪਲੀਕੇਸ਼ਨ ਹਨ ਜੋ ਅਸੀਂ ਕਰਨ ਦੇ ਯੋਗ ਸੀ:
  1. jsonnet ਕੋਡ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ। ਇਹ, ਉਦਾਹਰਨ ਲਈ, ਸਾਡੀ ਡਰੋਨ ਅਸੈਂਬਲੀ ਪਾਈਪਲਾਈਨ ਹੈ, ਜੋ ਕਿ ਕਾਫ਼ੀ ਗੁੰਝਲਦਾਰ ਹੈ। jsonnet ਕੋਡ ਟੈਸਟਾਂ ਦੁਆਰਾ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਵਰ ਕੀਤਾ ਗਿਆ ਹੈ।
     ਅਸੀਂ ਇਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ Jsonnet ਲਈ ਯੂਨਿਟ ਟੈਸਟਿੰਗ ਫਰੇਮਵਰਕ.
  2. ਸਕ੍ਰਿਪਟਾਂ ਲਈ ਟੈਸਟ ਜੋ ਸਰੋਤ ਦੇ ਸ਼ੁਰੂ ਹੋਣ 'ਤੇ ਲਾਗੂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਸਕ੍ਰਿਪਟਾਂ ਪਾਈਥਨ ਵਿੱਚ ਲਿਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਇਸਲਈ ਉਹਨਾਂ ਉੱਤੇ ਟੈਸਟ ਲਿਖੇ ਜਾ ਸਕਦੇ ਹਨ।
• ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਟੈਸਟਾਂ ਵਿੱਚ ਸੰਰਚਨਾ ਦੀ ਜਾਂਚ ਕਰਨਾ ਸੰਭਵ ਹੈ, ਪਰ ਅਸੀਂ ਅਜਿਹਾ ਨਹੀਂ ਕਰਦੇ ਹਾਂ। ਦੁਆਰਾ ਸਰੋਤ ਸੰਰਚਨਾ ਨਿਯਮਾਂ ਦੀ ਜਾਂਚ ਕਰਨਾ ਵੀ ਸੰਭਵ ਹੈ tflint. ਹਾਲਾਂਕਿ, ਟੈਰਾਫਾਰਮ ਲਈ ਉੱਥੇ ਦੀਆਂ ਜਾਂਚਾਂ ਬਹੁਤ ਬੁਨਿਆਦੀ ਹਨ, ਪਰ ਬਹੁਤ ਸਾਰੀਆਂ ਟੈਸਟ ਸਕ੍ਰਿਪਟਾਂ AWS ਲਈ ਲਿਖੀਆਂ ਗਈਆਂ ਹਨ। ਅਤੇ ਅਸੀਂ Azure 'ਤੇ ਹਾਂ, ਇਸ ਲਈ ਇਹ ਦੁਬਾਰਾ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ ਹੈ।
• ਕੰਪੋਨੈਂਟ ਏਕੀਕਰਣ ਟੈਸਟ: ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰਦੇ ਹੋ ਅਤੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਕਿੱਥੇ ਰੱਖਦੇ ਹੋ। ਪਰ ਉਹ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ.

  ਏਕੀਕਰਣ ਟੈਸਟ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ।

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

  ਚਿੱਤਰ ਪੁਸ਼ਟੀਕਰਨ ਐਲਗੋਰਿਦਮ

  1. ਪੈਕਰ ਨੂੰ ਪਹਿਲਾਂ ਚਿੱਤਰ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤਿਆਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
  2. ਟੈਸਟ ਦੇ ਅੱਗੇ ਇੱਕ ਸਥਾਨਕ ਰਾਜ ਦੇ ਨਾਲ ਇੱਕ ਟੈਰਾਫਾਰਮ ਹੈ, ਜਿਸਦੀ ਵਰਤੋਂ ਅਸੀਂ ਇਸ ਚਿੱਤਰ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਲਈ ਕਰਦੇ ਹਾਂ।
  3. ਜਦੋਂ ਸਾਹਮਣੇ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਚਿੱਤਰ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਣ ਲਈ ਨੇੜੇ ਪਏ ਇੱਕ ਛੋਟੇ ਮੋਡੀਊਲ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
  4. ਇੱਕ ਵਾਰ ਚਿੱਤਰ ਤੋਂ VM ਤੈਨਾਤ ਹੋ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਜਾਂਚ ਸ਼ੁਰੂ ਹੋ ਸਕਦੀ ਹੈ। ਅਸਲ ਵਿੱਚ, ਜਾਂਚ ਕਾਰ ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ. ਇਹ ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਸਕ੍ਰਿਪਟਾਂ ਨੇ ਸ਼ੁਰੂਆਤ ਤੇ ਕਿਵੇਂ ਕੰਮ ਕੀਤਾ ਅਤੇ ਡੈਮਨ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ssh ਜਾਂ winrm ਦੁਆਰਾ ਅਸੀਂ ਨਵੀਂ ਉਠਾਈ ਮਸ਼ੀਨ ਵਿੱਚ ਲੌਗਇਨ ਕਰਦੇ ਹਾਂ ਅਤੇ ਸੰਰਚਨਾ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ਜਾਂ ਸੇਵਾਵਾਂ ਚਾਲੂ ਹਨ ਜਾਂ ਨਹੀਂ।

• ਸਥਿਤੀ ਟੈਰਾਫਾਰਮ ਲਈ ਮੋਡੀਊਲਾਂ ਵਿੱਚ ਏਕੀਕਰਣ ਟੈਸਟਾਂ ਦੇ ਸਮਾਨ ਹੈ। ਇੱਥੇ ਅਜਿਹੇ ਟੈਸਟਾਂ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਨ ਵਾਲੀ ਇੱਕ ਛੋਟੀ ਸਾਰਣੀ ਹੈ।

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

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

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

ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਇੱਕ ਸੇਵਾ ਵਜੋਂ ScaleFT ਹੈ, ਸਾਨੂੰ API ਦੁਆਰਾ ਇਸ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਉੱਥੇ ਇੱਕ ਰੈਪਰ ਲਿਖਿਆ ਹੋਇਆ ਸੀ ਜਿਸਨੂੰ ਤੁਸੀਂ ਖਿੱਚ ਸਕਦੇ ਹੋ ਅਤੇ ਕਹਿ ਸਕਦੇ ਹੋ: "ਅੰਦਰ ਜਾਉ ਅਤੇ ਇਹ ਅਤੇ ਉਹ ਨੂੰ ਮਿਟਾਓ।" ਇਹ ਸਾਰੀਆਂ ਲੋੜੀਂਦੀਆਂ ਸੈਟਿੰਗਾਂ ਅਤੇ ਪਹੁੰਚਾਂ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ।

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

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

ਜੋੜਾ ਪ੍ਰੋਗਰਾਮਿੰਗ

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

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

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

ਹੇਠਾਂ ਜੋੜਾ ਪ੍ਰੋਗਰਾਮਿੰਗ ਸਟਾਈਲ ਅਤੇ IaC 'ਤੇ ਕੰਮ ਕਰਨ ਲਈ ਉਹਨਾਂ ਦੀ ਉਪਯੋਗਤਾ ਹਨ:

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

ਆਓ ਸ਼ੈਲੀ ਨਾਲ ਸਾਡੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦੀ ਅਨੁਕੂਲਤਾ 'ਤੇ ਵਿਚਾਰ ਕਰੀਏ:

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

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

ਸਿੱਟਾ: ਇਸਦੇ ਸ਼ੁੱਧ ਰੂਪ ਵਿੱਚ ਇਹ ਸਾਡੇ ਲਈ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ.

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

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

ਸਿੱਟਾ: ਹਾਏ, ਕੰਮ ਦੀ ਗਤੀ IaC ਵਿੱਚ ਇੱਕ ਜੋੜਾ ਪ੍ਰੋਗਰਾਮਿੰਗ ਅਭਿਆਸ ਵਜੋਂ ਪਿੰਗ-ਪੌਂਗ ਦੀ ਵਰਤੋਂ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੀ।

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

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

ਸਿੱਟਾ: ਇਹ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਅਸੀਂ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਨਹੀਂ ਛੱਡ ਰਹੇ ਹਾਂ।

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

ਜੋੜਾ ਪ੍ਰੋਗਰਾਮਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਆਮ ਨਤੀਜੇ:

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

5. ਇਸ ਦੇ ਬਾਵਜੂਦ, ਸਫਲਤਾਵਾਂ ਸਨ. ਅਸੀਂ ਆਪਣੀ ਖੁਦ ਦੀ ਵਿਧੀ "ਕਨਵਰਜੈਂਸ - ਡਾਇਵਰਜੈਂਸ" ਲੈ ਕੇ ਆਏ ਹਾਂ। ਮੈਂ ਸੰਖੇਪ ਵਿੱਚ ਵਰਣਨ ਕਰਾਂਗਾ ਕਿ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਸਾਡੇ ਕੋਲ ਕੁਝ ਦਿਨਾਂ (ਇੱਕ ਹਫ਼ਤੇ ਤੋਂ ਘੱਟ) ਲਈ ਸਥਾਈ ਭਾਈਵਾਲ ਹਨ। ਅਸੀਂ ਇਕੱਠੇ ਇੱਕ ਕੰਮ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਕੁਝ ਸਮੇਂ ਲਈ ਇਕੱਠੇ ਬੈਠਦੇ ਹਾਂ: ਇੱਕ ਲਿਖਦਾ ਹੈ, ਦੂਜਾ ਬੈਠਦਾ ਹੈ ਅਤੇ ਸਹਾਇਤਾ ਟੀਮ ਨੂੰ ਦੇਖਦਾ ਹੈ। ਫਿਰ ਅਸੀਂ ਕੁਝ ਸਮੇਂ ਲਈ ਖਿੰਡ ਜਾਂਦੇ ਹਾਂ, ਹਰ ਕੋਈ ਕੁਝ ਸੁਤੰਤਰ ਕੰਮ ਕਰਦਾ ਹੈ, ਫਿਰ ਅਸੀਂ ਦੁਬਾਰਾ ਇਕੱਠੇ ਹੁੰਦੇ ਹਾਂ, ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਸਮਕਾਲੀ ਹੋ ਜਾਂਦੇ ਹਾਂ, ਇਕੱਠੇ ਕੁਝ ਕਰਦੇ ਹਾਂ ਅਤੇ ਫਿਰ ਦੁਬਾਰਾ ਖਿੰਡ ਜਾਂਦੇ ਹਾਂ।

ਯੋਜਨਾ ਅਤੇ ਸੰਚਾਰ

ਅਭਿਆਸਾਂ ਦਾ ਆਖਰੀ ਬਲਾਕ ਜਿਸ ਦੁਆਰਾ OS ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਹੱਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਕਾਰਜਾਂ ਦੇ ਨਾਲ ਕੰਮ ਦਾ ਸੰਗਠਨ ਹੈ. ਇਸ ਵਿੱਚ ਤਜਰਬੇ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਵੀ ਸ਼ਾਮਲ ਹੈ ਜੋ ਜੋੜੇ ਦੇ ਕੰਮ ਤੋਂ ਬਾਹਰ ਹੈ। ਆਓ ਤਿੰਨ ਅਭਿਆਸਾਂ ਨੂੰ ਵੇਖੀਏ:

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

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

ਕਾਰਜਾਂ ਦੀ ਵਿਜ਼ੂਅਲ ਦ੍ਰਿਸ਼ਟੀ ਦੇ ਫਾਇਦੇ:

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

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

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

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

ਇਸ ਦਾ ਹੱਲ ਇੱਕ ਦੂਜੇ ਨੂੰ ਕੀਤੇ ਕੰਮ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਕਰਨ ਅਤੇ ਫਿਰ ਚਰਚਾ ਕਰਨ ਵਿੱਚ ਲੱਭਿਆ ਗਿਆ। ਅਸੀਂ ਹਫ਼ਤੇ ਵਿੱਚ ਇੱਕ ਵਾਰ ਇੱਕ ਘੰਟੇ ਲਈ ਮਿਲਦੇ ਹਾਂ ਅਤੇ ਪਿਛਲੇ ਹਫ਼ਤੇ ਵਿੱਚ ਕੀਤੇ ਗਏ ਕੰਮਾਂ ਦੇ ਹੱਲ ਦੇ ਵੇਰਵੇ ਦਿਖਾਉਂਦੇ ਹਾਂ।

ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਦੌਰਾਨ, ਕਾਰਜ ਦੇ ਵੇਰਵਿਆਂ ਨੂੰ ਪ੍ਰਗਟ ਕਰਨਾ ਅਤੇ ਇਸਦੇ ਕਾਰਜ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨਾ ਯਕੀਨੀ ਬਣਾਉਣਾ ਜ਼ਰੂਰੀ ਹੈ.

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

2. ਪਹਿਲਾਂ ਸਮੱਸਿਆ ਕਿਵੇਂ ਹੱਲ ਕੀਤੀ ਗਈ ਸੀ? ਉਦਾਹਰਨ ਲਈ, ਵੱਡੇ ਮਾਊਸ ਕਲਿੱਕ ਕਰਨ ਦੀ ਲੋੜ ਸੀ, ਜਾਂ ਕੁਝ ਵੀ ਕਰਨਾ ਅਸੰਭਵ ਸੀ।

3. ਅਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਸੁਧਾਰਦੇ ਹਾਂ। ਉਦਾਹਰਨ ਲਈ: "ਦੇਖੋ, ਹੁਣ ਸਕ੍ਰਿਪਟੋਸਿਕ ਹੈ, ਇੱਥੇ ਰੀਡਮੀ ਹੈ।"

4. ਦਿਖਾਓ ਕਿ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਕੁਝ ਉਪਭੋਗਤਾ ਦ੍ਰਿਸ਼ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕਰਨ ਦੀ ਸਲਾਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਮੈਨੂੰ X ਚਾਹੀਦਾ ਹੈ, ਮੈਂ Y ਕਰਦਾ ਹਾਂ, ਮੈਂ Y (ਜਾਂ Z) ਨੂੰ ਵੇਖਦਾ ਹਾਂ। ਉਦਾਹਰਨ ਲਈ, ਮੈਂ NGINX ਨੂੰ ਤੈਨਾਤ ਕਰਦਾ ਹਾਂ, url ਨੂੰ ਸਮੋਕ ਕਰਦਾ ਹਾਂ, ਅਤੇ 200 OK ਪ੍ਰਾਪਤ ਕਰਦਾ ਹਾਂ. ਜੇਕਰ ਕਾਰਵਾਈ ਲੰਬੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਤਿਆਰ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਇਸਨੂੰ ਬਾਅਦ ਵਿੱਚ ਦਿਖਾ ਸਕੋ। ਇਹ ਸਲਾਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਡੈਮੋ ਤੋਂ ਇੱਕ ਘੰਟਾ ਪਹਿਲਾਂ ਇਸਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਾ ਤੋੜੋ, ਜੇ ਇਹ ਨਾਜ਼ੁਕ ਹੈ।

5. ਸਮਝਾਓ ਕਿ ਸਮੱਸਿਆ ਨੂੰ ਕਿੰਨੀ ਸਫਲਤਾਪੂਰਵਕ ਹੱਲ ਕੀਤਾ ਗਿਆ, ਕਿਹੜੀਆਂ ਮੁਸ਼ਕਲਾਂ ਬਚੀਆਂ ਹਨ, ਕਿਹੜੀਆਂ ਪੂਰੀਆਂ ਨਹੀਂ ਹੋਈਆਂ, ਭਵਿੱਖ ਵਿੱਚ ਕਿਹੜੇ ਸੁਧਾਰ ਸੰਭਵ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਹੁਣ CLI, ਫਿਰ CI ਵਿੱਚ ਪੂਰਾ ਆਟੋਮੇਸ਼ਨ ਹੋਵੇਗਾ।

ਹਰੇਕ ਸਪੀਕਰ ਨੂੰ ਇਸ ਨੂੰ 5-10 ਮਿੰਟ ਤੱਕ ਰੱਖਣ ਦੀ ਸਲਾਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਜੇਕਰ ਤੁਹਾਡੀ ਬੋਲੀ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗੇਗਾ, ਤਾਂ ਇਸ ਨੂੰ ਪਹਿਲਾਂ ਹੀ sre-takeover ਚੈਨਲ ਵਿੱਚ ਤਾਲਮੇਲ ਕਰੋ।

ਫੇਸ-ਟੂ-ਫੇਸ ਭਾਗ ਤੋਂ ਬਾਅਦ ਧਾਗੇ ਵਿੱਚ ਹਮੇਸ਼ਾ ਚਰਚਾ ਹੁੰਦੀ ਹੈ। ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਸਾਨੂੰ ਸਾਡੇ ਕੰਮਾਂ 'ਤੇ ਫੀਡਬੈਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

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

ਲੰਬੇ ਸਿੱਟੇ ਅਤੇ ਅੱਗੇ ਕੀ ਹੈ

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

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

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

OS ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਦੇ ਉੱਚ-ਪੱਧਰੀ ਤਰੀਕੇ - ਕਾਰਜਾਂ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣਾ ਅਤੇ ਕੰਮ ਕਰਨਾ ਸਹੀ ਰੂਪ ਵਿੱਚ ਪ੍ਰਭਾਵ ਪੈਦਾ ਕਰਦਾ ਹੈ: ਉੱਚ-ਗੁਣਵੱਤਾ ਦੇ ਗਿਆਨ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਅਤੇ ਬਿਹਤਰ ਵਿਕਾਸ ਗੁਣਵੱਤਾ।

ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਛੋਟੇ ਸਿੱਟੇ

• HR ਪ੍ਰੈਕਟੀਸ਼ਨਰ IaC ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ, ਪਰ ਘੱਟ ਕੁਸ਼ਲਤਾ ਨਾਲ।
• ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ ਉਸ ਨੂੰ ਮਜ਼ਬੂਤ ​​ਕਰੋ।
• ਆਪਣੇ ਖੁਦ ਦੇ ਮੁਆਵਜ਼ੇ ਦੀ ਵਿਧੀ ਅਤੇ ਅਭਿਆਸਾਂ ਦੇ ਨਾਲ ਆਓ।

ਸਰੋਤ: www.habr.com