ਡਿਵੈਲਪਰਾਂ ਲਈ ਵਧੀਆ DevOps ਅਭਿਆਸ। ਐਂਟਨ ਬੋਏਕੋ (2017)

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

ਮੈਨੂੰ ਆਪਣੀ ਜਾਣ-ਪਛਾਣ ਕਰਨ ਦਿਓ, ਮੈਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਵੀਕਾਰ ਕਰਦਾ ਹਾਂ ਕਿ ਕਮਰੇ ਵਿੱਚ ਅਜਿਹੇ ਲੋਕ ਹਨ ਜੋ ਮੈਨੂੰ ਨਹੀਂ ਜਾਣਦੇ। ਮੇਰਾ ਨਾਮ ਐਂਟਨ ਬੋਏਕੋ ਹੈ, ਮੈਂ ਇੱਕ ਮਾਈਕ੍ਰੋਸਾਫਟ ਅਜ਼ੁਰ ਐਮਵੀਪੀ ਹਾਂ। MVP ਕੀ ਹੈ? ਇਹ ਮਾਡਲ-ਦ੍ਰਿਸ਼-ਪ੍ਰਸਤੁਤਕ ਹੈ। ਮਾਡਲ-ਵਿਊ-ਪ੍ਰੇਜ਼ੈਂਟਰ ਬਿਲਕੁਲ ਮੈਂ ਹਾਂ।

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

ਮੇਰੇ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ:

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

ਏਜੰਡੇ ਬਾਰੇ ਥੋੜੀ ਗੱਲ ਕਰੀਏ। ਸਾਡਾ ਏਜੰਡਾ ਬਹੁਤ ਸਧਾਰਨ ਹੈ:

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

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

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

ਇਹ ਸਭ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਲੋਕ ਇੱਕ ਦੂਜੇ ਨਾਲ ਸੰਚਾਰ ਨਹੀਂ ਕਰਦੇ ਹਨ। ਅਤੇ ਉਹ ਗਲਤਫਹਿਮੀ ਦੀ ਕਿਸੇ ਕੰਧ ਰਾਹੀਂ ਇੱਕ ਦੂਜੇ ਨੂੰ ਕੁਝ ਪੈਕੇਜ, ਕੁਝ ਐਪਲੀਕੇਸ਼ਨ ਸੁੱਟ ਦਿੰਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨਾਲ ਕੁਝ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ.

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

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

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

ਇਸ ਸਲਾਈਡ ਦਾ ਦੂਜਾ ਅਣਅਧਿਕਾਰਤ ਨਾਮ ਵੀ ਹੈ। ਤੁਸੀਂ ਇਹ ਪਤਾ ਲਗਾਉਣ ਲਈ ਔਨਲਾਈਨ ਖੋਜ ਕਰ ਸਕਦੇ ਹੋ ਕਿ DevOps ਦੇ 3 ਮਸਕੇਟੀਅਰ ਕੀ ਹਨ। ਇਹ ਸੰਭਵ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਇਹ ਲੇਖ ਮਿਲੇਗਾ. 3 ਮਸਕੇਟੀਅਰ ਕਿਉਂ? ਹੇਠਾਂ ਇਹ ਲਿਖਿਆ ਹੈ: ਲੋਕ, ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਉਤਪਾਦ, i.e. PPP - ਪੋਰਥੋਸ, ਪੋਰਟਹੋਸ ਅਤੇ ਪੋਰਟਹੋਸ। ਇੱਥੇ DevOps ਦੇ 3 ਮਸਕੇਟੀਅਰ ਹਨ। ਇਹ ਲੇਖ ਵਧੇਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਕੀ ਸ਼ਾਮਲ ਹੈ।

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

ਸ਼ੁਰੂ ਵਿੱਚ ਤੁਹਾਨੂੰ ਲੋਕਾਂ ਨਾਲ ਗੱਲ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਅਤੇ ਤੁਹਾਨੂੰ ਲੋਕਾਂ ਨੂੰ ਇਹ ਸਮਝਾਉਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਇਹ ਕੀ ਹੈ ਅਤੇ ਉਹ ਇਸ ਤੋਂ ਕੁਝ ਲਾਭ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਨ।

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

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

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

QAs ਸਭ ਤੋਂ ਵੱਧ ਕੀ ਚਾਹੁੰਦੇ ਹਨ? ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਉਹ ਹਾਲ ਵਿੱਚ ਹਨ ਜਾਂ ਨਹੀਂ। ਮੇਰੇ ਲਈ ਇਹ ਕਹਿਣਾ ਔਖਾ ਹੈ ਕਿ ਮੈਂ QA ਚਾਹੁੰਦਾ ਹਾਂ, ਕਿਉਂਕਿ ਮੈਂ ਕਦੇ ਇੱਕ ਨਹੀਂ ਰਿਹਾ। ਅਤੇ ਮੁੰਡਿਆਂ ਨੂੰ ਕੋਈ ਅਪਰਾਧ ਨਹੀਂ, ਇਹ ਕਿਹਾ ਜਾਵੇਗਾ ਕਿ ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਮੈਂ ਕਦੇ ਨਹੀਂ ਕਰਾਂਗਾ. ਪਰ ਇਸ ਕਾਰਨ ਨਹੀਂ ਕਿ ਮੈਂ ਉਨ੍ਹਾਂ ਦੇ ਕੰਮ ਨੂੰ ਅਰਥਹੀਣ ਅਤੇ ਬੇਕਾਰ ਸਮਝਦਾ ਹਾਂ, ਪਰ ਕਿਉਂਕਿ ਮੈਂ ਆਪਣੇ ਆਪ ਨੂੰ ਅਜਿਹਾ ਵਿਅਕਤੀ ਨਹੀਂ ਸਮਝਦਾ ਜੋ ਇਸ ਕੰਮ ਨੂੰ ਕੁਸ਼ਲਤਾ ਨਾਲ ਕਰ ਸਕੇ, ਇਸ ਲਈ ਮੈਂ ਇਸ ਨੂੰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਵੀ ਨਹੀਂ ਕਰਾਂਗਾ। ਪਰ ਜੋ ਮੈਂ ਸਮਝਦਾ ਹਾਂ ਉਸ ਤੋਂ, QA ਜੋ ਸਭ ਤੋਂ ਵੱਧ ਪਸੰਦ ਨਹੀਂ ਕਰਦਾ ਉਹ ਹੈ ਸਵੇਰੇ ਕੰਮ ਕਰਨਾ, ਲਗਾਤਾਰ ਕੁਝ ਕਿਸਮ ਦੇ ਰੀਗਰੈਸ਼ਨ ਟੈਸਟਾਂ ਨੂੰ ਚਲਾਉਣਾ, ਉਸੇ ਬੱਗ 'ਤੇ ਕਦਮ ਰੱਖਣਾ ਜੋ ਉਨ੍ਹਾਂ ਨੇ 3 ਸਪ੍ਰਿੰਟ ਪਹਿਲਾਂ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਰਿਪੋਰਟ ਕੀਤਾ ਸੀ ਅਤੇ ਕਿਹਾ: "ਤੁਸੀਂ ਕਦੋਂ ਕਰੋਗੇ , Monsieur D 'Artagnan, ਇਸ ਬੱਗ ਨੂੰ ਠੀਕ ਕਰੋ।' ਅਤੇ ਮੋਨਸੀਅਰ ਡੀ ਆਰਟਗਨਨ ਨੇ ਉਸਨੂੰ ਜਵਾਬ ਦਿੱਤਾ: "ਹਾਂ, ਹਾਂ, ਹਾਂ, ਮੈਂ ਇਸਨੂੰ ਪਹਿਲਾਂ ਹੀ ਠੀਕ ਕਰ ਲਿਆ ਹੈ." ਅਤੇ ਇਹ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ ਕਿ ਮੈਂ ਇੱਕ ਬੱਗ ਨੂੰ ਠੀਕ ਕੀਤਾ ਅਤੇ ਰਸਤੇ ਵਿੱਚ 5 ਬਣਾਏ।

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

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

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

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

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

ਆਉ ਆਮ ਤੌਰ 'ਤੇ DevOps ਅਭਿਆਸਾਂ ਬਾਰੇ ਗੱਲ ਕਰੀਏ। ਉਹ ਕੀ ਹਨ? ਕੀ ਫਰਕ ਹੈ? ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਅਜ਼ਮਾਉਣਾ ਹੈ? ਉਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹਨ?

ਪਹਿਲਾ ਅਭਿਆਸ ਜਿਸ ਬਾਰੇ ਤੁਸੀਂ ਸੁਣਿਆ ਹੋਵੇਗਾ ਉਸਨੂੰ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਸ਼ਾਇਦ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਕਿਸੇ ਕੋਲ ਨਿਰੰਤਰ ਏਕੀਕਰਣ (CI) ਹੈ।

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

ਵਾਸਤਵ ਵਿੱਚ, CI ਦਾ ਅਭਿਆਸ ਸਿਰਫ ਕੋਡ ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਕਰਨ ਦਾ ਉਦੇਸ਼ ਹੈ ਜੋ ਵੱਖ-ਵੱਖ ਲੋਕ ਕਿਸੇ ਕਿਸਮ ਦੇ ਸਿੰਗਲ ਕੋਡ ਅਧਾਰ ਵਿੱਚ ਲਿਖਦੇ ਹਨ। ਇਹ ਸਭ ਹੈ.

CI ਦੇ ਨਾਲ, ਰਸਤੇ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਹੋਰ ਅਭਿਆਸ ਹੁੰਦੇ ਹਨ - ਜਿਵੇਂ ਕਿ ਨਿਰੰਤਰ ਤਾਇਨਾਤੀ, ਰੀਲੀਜ਼ ਪ੍ਰਬੰਧਨ, ਪਰ ਅਸੀਂ ਇਸ ਬਾਰੇ ਬਾਅਦ ਵਿੱਚ ਗੱਲ ਕਰਾਂਗੇ।

CI ਖੁਦ ਸਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਵੱਖ-ਵੱਖ ਲੋਕ ਕੋਡ ਲਿਖਦੇ ਹਨ ਅਤੇ ਇਸ ਕੋਡ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਕੋਡ ਬੇਸ ਵਿੱਚ ਲਗਾਤਾਰ ਜੋੜਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

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

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

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

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

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

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

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

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

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

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

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

ਸਾਡੇ ਕੋਲ ਇੱਕ ਹੋਰ ਅਭਿਆਸ ਆਟੋਮੇਸ਼ਨ ਟੈਸਟਿੰਗ ਅਭਿਆਸ ਹੈ, ਜੋ ਕਿ ਅਕਸਰ CI ਅਭਿਆਸ ਨਾਲ ਆਉਂਦਾ ਹੈ। ਉਹ ਹੱਥ ਮਿਲਾਉਂਦੇ ਹਨ।

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

ਸਾਡੇ ਕੋਲ ਏਕੀਕਰਣ ਟੈਸਟ ਵੀ ਹਨ ਜੋ ਸਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ ਕਿ ਵੱਖ-ਵੱਖ ਮੋਡੀਊਲ ਇੱਕ ਦੂਜੇ ਨਾਲ ਕਿਵੇਂ ਏਕੀਕ੍ਰਿਤ ਹੁੰਦੇ ਹਨ। ਇਹ ਵੀ ਚੰਗਾ ਹੈ।

ਸਾਡੇ ਕੋਲ UI ਆਟੋਮੇਸ਼ਨ ਟੈਸਟ ਹੋ ਸਕਦੇ ਹਨ ਜੋ ਸਾਨੂੰ ਇਹ ਜਾਂਚ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ ਕਿ UI ਦੇ ਨਾਲ ਕੰਮ ਗਾਹਕ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੁਝ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ, ਆਦਿ।

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

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

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

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

ਨਿਰੰਤਰ ਤੈਨਾਤੀ ਦਾ ਅਭਿਆਸ ਕਰੋ। ਬਹੁਤ ਵਧੀਆ, ਤੁਸੀਂ ਬਿਲਡ ਪੂਰਾ ਕਰ ਲਿਆ ਹੈ। ਇਹ ਪਹਿਲਾਂ ਹੀ ਚੰਗਾ ਹੈ। ਤੁਹਾਡਾ ਕੋਡ ਕੰਪਾਇਲ ਹੋ ਗਿਆ ਹੈ। ਹੁਣ ਇਸ ਬਿਲਡ ਨੂੰ ਕਿਸੇ ਵਾਤਾਵਰਨ 'ਤੇ ਤੈਨਾਤ ਕਰਨਾ ਚੰਗਾ ਹੋਵੇਗਾ। ਆਓ ਡਿਵੈਲਪਰਾਂ ਲਈ ਇੱਕ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕਹੀਏ.

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ? ਪਹਿਲਾਂ, ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਤੈਨਾਤੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਨਾਲ ਕਿੰਨੇ ਸਫਲ ਹੋ। ਮੈਂ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਮਿਲਿਆ ਹਾਂ, ਜਦੋਂ ਮੈਂ ਪੁੱਛਦਾ ਹਾਂ: "ਤੁਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਨਵਾਂ ਸੰਸਕਰਣ ਕਿਵੇਂ ਲਾਗੂ ਕਰਦੇ ਹੋ?", ਮੁੰਡੇ ਮੈਨੂੰ ਦੱਸਦੇ ਹਨ: "ਅਸੀਂ ਇਸਨੂੰ ਇਕੱਠੇ ਕਰਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਜ਼ਿਪ ਆਰਕਾਈਵ ਵਿੱਚ ਪੈਕ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਇਸਨੂੰ ਡਾਕ ਰਾਹੀਂ ਐਡਮਿਨ ਨੂੰ ਭੇਜਦੇ ਹਾਂ। ਪ੍ਰਸ਼ਾਸਕ ਇਸ ਆਰਕਾਈਵ ਨੂੰ ਡਾਊਨਲੋਡ ਅਤੇ ਵਿਸਤਾਰ ਕਰਦਾ ਹੈ। ਅਤੇ ਸਾਰਾ ਦਫਤਰ ਪ੍ਰਾਰਥਨਾ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ ਕਿ ਸਰਵਰ ਨਵਾਂ ਸੰਸਕਰਣ ਚੁਣ ਲਵੇ। ”

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

ਨਾਲ ਹੀ, ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਦੂਜੇ ਦੇ ਵਿਚਕਾਰ ਕੋਡ ਨੂੰ ਜੋੜਦੇ ਹੋ, i.e. ਕਮਾਂਡ ਦੇ ਵਿਚਕਾਰ, ਇਹ ਤੁਹਾਨੂੰ ਇਹ ਵੀ ਦੇਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਕਿ ਇਹ UI 'ਤੇ ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।

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

ਅਗਲਾ ਅਭਿਆਸ ਜੋ ਸਾਡੇ ਕੋਲ ਹੈ ਉਹ ਆਟੋਮੈਟਿਕ ਰੀਸਟੋਰ ਦਾ ਅਭਿਆਸ ਹੈ, ਅਰਥਾਤ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਪਿਛਲੇ ਸੰਸਕਰਣ 'ਤੇ ਵਾਪਸ ਜਾਣਾ।

ਡਿਵੈਲਪਰਾਂ ਲਈ ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ? ਅਜੇ ਵੀ ਉਹ ਲੋਕ ਹਨ ਜੋ ਦੂਰ, ਦੂਰ ਦੇ 90 ਦੇ ਦਹਾਕੇ ਨੂੰ ਯਾਦ ਕਰਦੇ ਹਨ, ਜਦੋਂ ਕੰਪਿਊਟਰ ਵੱਡੇ ਸਨ ਅਤੇ ਪ੍ਰੋਗਰਾਮ ਛੋਟੇ ਸਨ. ਅਤੇ ਵੈੱਬ ਵਿਕਾਸ ਦਾ ਇੱਕੋ ਇੱਕ ਤਰੀਕਾ PHP ਦੁਆਰਾ ਸੀ. ਇਹ ਨਹੀਂ ਹੈ ਕਿ PHP ਇੱਕ ਮਾੜੀ ਭਾਸ਼ਾ ਹੈ, ਹਾਲਾਂਕਿ ਇਹ ਹੈ.

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

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

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

ਹੁਣ ਆਉ ਕਿਸੇ ਤਰ੍ਹਾਂ ਦੋ ਪਿਛਲੀਆਂ ਪ੍ਰਥਾਵਾਂ ਨੂੰ ਇਕੱਠੇ ਜੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ। ਸਾਨੂੰ ਰੀਲੀਜ਼ ਮੈਨੇਜਮੈਂਟ ਨਾਮਕ ਤੀਜਾ ਪ੍ਰਾਪਤ ਹੋਵੇਗਾ।

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

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

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

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

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

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

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

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

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

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

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

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

ਅਗਲਾ ਅਭਿਆਸ, ਜੋ ਮੌਜੂਦ ਵੀ ਹੈ ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਵੀ ਹੈ, ਪਰ ਜਿਸ ਦੀ ਵਰਤੋਂ ਬਹੁਤ ਘੱਟ ਲੋਕ ਕਰਦੇ ਹਨ, ਉਹ ਹੈ ਐਪਲੀਕੇਸ਼ਨ ਪਰਫਾਰਮੈਂਸ ਮਾਨੀਟਰਿੰਗ।

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

ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ, ਲਗਭਗ ਹਰ ਬਿਲਡ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ ਚੰਗਾ ਹੋਵੇਗਾ, ਹਾਲਾਂਕਿ, ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ, ਇਹ ਹਮੇਸ਼ਾ ਸੰਭਵ ਨਹੀਂ ਹੁੰਦਾ ਹੈ। ਪਰ, ਘੱਟੋ-ਘੱਟ, ਹਰ ਰੀਲੀਜ਼ ਲਈ ਇਸ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

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

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

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

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

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

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

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

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

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

ਮੈਂ ਜਾਣਦਾ ਹਾਂ ਕਿ ਇਸ ਕਾਨਫਰੰਸ ਵਿੱਚ ਉਨ੍ਹਾਂ ਟੀਮਾਂ ਵਿੱਚੋਂ ਕਈ ਲੋਕ ਹਨ ਜਿਨ੍ਹਾਂ ਨਾਲ ਮੈਂ ਕੰਮ ਕਰਦਾ ਹਾਂ। ਅਤੇ ਉਨ੍ਹਾਂ ਸਾਰੀਆਂ ਟੀਮਾਂ ਦੇ ਨਾਲ ਜਿਨ੍ਹਾਂ ਨਾਲ ਮੈਂ ਕੰਮ ਕਰਦਾ ਹਾਂ, ਅਸੀਂ ਇਸ ਅਭਿਆਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

ਕਿਉਂ? ਬੇਸ਼ੱਕ, ਇਹ ਬਹੁਤ ਵਧੀਆ ਹੋਵੇਗਾ ਜੇਕਰ ਹਰੇਕ ਡਿਵੈਲਪਰ ਕੋਲ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਹੋਵੇ ਜੋ 24/7 ਕੰਮ ਕਰੇਗੀ। ਪਰ ਸ਼ਾਇਦ ਇਹ ਤੁਹਾਡੇ ਲਈ ਖ਼ਬਰ ਹੈ, ਸ਼ਾਇਦ ਤੁਸੀਂ ਧਿਆਨ ਨਹੀਂ ਦਿੱਤਾ, ਪਰ ਡਿਵੈਲਪਰ ਖੁਦ 24/7 ਕੰਮ ਨਹੀਂ ਕਰਦਾ. ਇੱਕ ਡਿਵੈਲਪਰ ਆਮ ਤੌਰ 'ਤੇ ਦਿਨ ਵਿੱਚ 8 ਘੰਟੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਭਾਵੇਂ ਉਹ ਜਲਦੀ ਕੰਮ 'ਤੇ ਆਉਂਦਾ ਹੈ, ਉਸ ਦਾ ਲੰਚ ਵੱਡਾ ਹੁੰਦਾ ਹੈ ਜਿਸ ਦੌਰਾਨ ਉਹ ਜਿਮ ਜਾਂਦਾ ਹੈ। ਇਸ ਨੂੰ ਦਿਨ ਵਿੱਚ 12 ਘੰਟੇ ਹੋਣ ਦਿਓ ਜਦੋਂ ਡਿਵੈਲਪਰ ਅਸਲ ਵਿੱਚ ਇਹਨਾਂ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਸਾਡੇ ਕਾਨੂੰਨ ਦੇ ਅਨੁਸਾਰ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਹਫ਼ਤੇ ਵਿੱਚ 5 ​​ਵਿੱਚੋਂ 7 ਦਿਨ ਹਨ ਜੋ ਕੰਮਕਾਜੀ ਦਿਨ ਮੰਨੇ ਜਾਂਦੇ ਹਨ।

ਇਸ ਹਿਸਾਬ ਨਾਲ ਹਫਤੇ ਦੇ ਦਿਨਾਂ 'ਚ ਇਹ ਮਸ਼ੀਨ 24 ਘੰਟੇ ਨਹੀਂ, ਸਗੋਂ ਸਿਰਫ 12 ਘੰਟੇ ਕੰਮ ਕਰੇਗੀ ਅਤੇ ਸ਼ਨੀਵਾਰ ਵਾਲੇ ਦਿਨ ਇਹ ਮਸ਼ੀਨ ਬਿਲਕੁਲ ਵੀ ਕੰਮ ਨਹੀਂ ਕਰੇਗੀ। ਇਹ ਲਗਦਾ ਹੈ ਕਿ ਸਭ ਕੁਝ ਬਹੁਤ ਸਾਦਾ ਹੈ, ਪਰ ਇੱਥੇ ਕੀ ਕਹਿਣਾ ਜ਼ਰੂਰੀ ਹੈ? ਇਸ ਬੁਨਿਆਦੀ ਅਨੁਸੂਚੀ 'ਤੇ ਇਸ ਸਧਾਰਨ ਅਭਿਆਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਨਾਲ, ਇਹ ਤੁਹਾਨੂੰ ਇਹਨਾਂ ਵਾਤਾਵਰਣਾਂ ਨੂੰ ਬਣਾਏ ਰੱਖਣ ਦੀ ਲਾਗਤ ਨੂੰ 70% ਤੱਕ ਘਟਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਯਾਨੀ ਤੁਸੀਂ ਆਪਣੇ dev, QA, ਡੈਮੋ, ਵਾਤਾਵਰਣ ਦੀ ਕੀਮਤ ਲਈ ਅਤੇ ਇਸਨੂੰ 3 ਨਾਲ ਵੰਡਿਆ।

ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਬਾਕੀ ਪੈਸੇ ਦਾ ਕੀ ਕੀਤਾ ਜਾਵੇ? ਉਦਾਹਰਨ ਲਈ, ਡਿਵੈਲਪਰਾਂ ਨੂੰ ReSharper ਖਰੀਦਣਾ ਚਾਹੀਦਾ ਹੈ ਜੇਕਰ ਉਹਨਾਂ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਨਹੀਂ ਹੈ। ਜਾਂ ਕਾਕਟੇਲ ਪਾਰਟੀ ਕਰੋ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਇੱਕ ਵਾਤਾਵਰਣ ਸੀ ਜਿਸ ਵਿੱਚ dev ਅਤੇ QA ਦੋਵੇਂ ਚਰਦੇ ਸਨ, ਅਤੇ ਇਹ ਹੀ ਹੈ, ਹੁਣ ਤੁਸੀਂ 3 ਵੱਖ-ਵੱਖ ਬਣਾ ਸਕਦੇ ਹੋ ਜੋ ਅਲੱਗ-ਥਲੱਗ ਹੋ ਜਾਣਗੇ, ਅਤੇ ਲੋਕ ਇੱਕ ਦੂਜੇ ਵਿੱਚ ਦਖਲ ਨਹੀਂ ਦੇਣਗੇ।

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

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

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

ਕੀ ਅਸੀਂ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਟੈਸਟ ਵਾਤਾਵਰਨ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਮਾਪਣ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ? ਭਾਵ, ਇਹ ਉਤਪਾਦਨ ਨਹੀਂ ਹੈ?

ਹਾਂ, ਇਹ ਉਤਪਾਦਨ ਨਹੀਂ ਹੈ, ਇਹ ਇੱਕ ਟੈਸਟ ਵਾਤਾਵਰਨ ਹੈ, ਜੋ ਹਮੇਸ਼ਾ ਇੱਕੋ ਜਿਹਾ ਹੁੰਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਪਿਛਲੇ ਮਾਪਾਂ ਨਾਲ ਇਸਦੀ ਤੁਲਨਾ ਕਰ ਸਕੋ।

ਸਮਝ ਗਿਆ ਧੰਨਵਾਦ!

ਜੇਕਰ ਕੋਈ ਸਵਾਲ ਨਹੀਂ ਹਨ, ਤਾਂ ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਅਸੀਂ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹਾਂ। ਤੁਹਾਡਾ ਧੰਨਵਾਦ!

ਸਰੋਤ: www.habr.com