ਭਾਗ 1: ਵੈੱਬ/ਐਂਡਰਾਇਡ

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

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

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

ਸਰੋਤ: http://maximelanciauxbi.blogspot.com/2017/04/devops-tools.html

ਇੱਥੇ ਅਸੀਂ ਸੰਭਵ ਤੌਰ 'ਤੇ ਸ਼ੁਰੂਆਤੀ ਹਿੱਸੇ ਦੇ ਨਾਲ ਖਤਮ ਕਰਾਂਗੇ ਅਤੇ ਇਸ ਲੇਖ ਦੇ ਉਦੇਸ਼ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਾਂਗੇ। 

ਇਹ ਲੇਖ ਕਿਸ ਬਾਰੇ ਹੈ?

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

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

ਇਸ ਲੇਖ ਵਿਚ ਕੀ ਨਹੀਂ ਹੈ

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

ਇਹ ਇਸ ਲਈ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ: 

• ਇਹ ਸਮੱਗਰੀ ਵੱਖ-ਵੱਖ ਸਰੋਤਾਂ (ਦਸਤਾਵੇਜ਼, ਕਿਤਾਬਾਂ, ਵੀਡੀਓ ਕੋਰਸ) ਵਿੱਚ ਲੱਭਣਾ ਬਹੁਤ ਆਸਾਨ ਹੈ;
• ਜੇਕਰ ਅਸੀਂ ਡੂੰਘਾਈ ਵਿੱਚ ਜਾਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਇਸ ਲੇਖ ਦੇ 10, 20, 30 ਹਿੱਸੇ ਲਿਖਣੇ ਪੈਣਗੇ (ਜਦੋਂ ਕਿ ਯੋਜਨਾਵਾਂ 2-3 ਹਨ);
• ਮੈਂ ਤੁਹਾਡਾ ਸਮਾਂ ਬਰਬਾਦ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇੱਕੋ ਟੀਚੇ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਹੋਰ ਸਾਧਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਚਾਹ ਸਕਦੇ ਹੋ।

ਪ੍ਰੈਕਟਿਸ

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

ਯੋਜਨਾ

ਕਦਮ
ਤਕਨਾਲੋਜੀ
ਸੰਦ

1
ਸਥਾਨਕ ਚੱਲ ਰਿਹਾ ਹੈ (ਵੈੱਬ/ਐਂਡਰੋਇਡ ਡੈਮੋ ਟੈਸਟ ਤਿਆਰ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਚਲਾਓ) 
Node.js, Selenium, Appium

2
ਸੰਸਕਰਣ ਕੰਟਰੋਲ ਸਿਸਟਮ 
ਗਿੱਟ

3
ਕੰਟੇਨਰਾਈਜ਼ੇਸ਼ਨ
ਡੌਕਰ, ਸੇਲੇਨਿਅਮ ਗਰਿੱਡ, ਸੇਲੇਨੋਇਡ (ਵੈੱਬ, ਐਂਡਰੌਇਡ)

4
CI/CD
ਗਿਟਲੈਬ ਸੀ.ਆਈ

5
ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ
Google ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ

6
ਆਰਕੈਸਟਰੇਸ਼ਨ
ਕਬਰਨੇਟਿਸ

7
ਇੱਕ ਕੋਡ (IaC) ਦੇ ਰੂਪ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚਾ
ਟੈਰਾਫਾਰਮ, ਜਵਾਬਦੇਹ

ਹਰੇਕ ਭਾਗ ਦੀ ਬਣਤਰ

ਬਿਰਤਾਂਤ ਨੂੰ ਸਪਸ਼ਟ ਰੱਖਣ ਲਈ, ਹਰੇਕ ਭਾਗ ਨੂੰ ਹੇਠ ਲਿਖੀ ਰੂਪਰੇਖਾ ਅਨੁਸਾਰ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ:

• ਤਕਨਾਲੋਜੀ ਦਾ ਸੰਖੇਪ ਵੇਰਵਾ,
• ਆਟੋਮੇਸ਼ਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ ਮੁੱਲ,
• ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਦਾ ਦ੍ਰਿਸ਼ਟਾਂਤ,
• ਅਧਿਐਨ ਕਰਨ ਲਈ ਲਿੰਕ,
• ਸਮਾਨ ਸੰਦ।

1. ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਟੈਸਟ ਚਲਾਓ

ਤਕਨਾਲੋਜੀ ਦਾ ਸੰਖੇਪ ਵਰਣਨ

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

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

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

ਆਟੋਮੇਸ਼ਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ ਮੁੱਲ

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

ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਦਾ ਚਿੱਤਰ

ਪੜਚੋਲ ਕਰਨ ਲਈ ਲਿੰਕ

• ਸੇਲੇਨਿਅਮ
• ਐਪੀਅਸ
• ਛੁਪਾਓ ਈਮੂਲੇਟਰ
• ਸੇਲੇਨਿਅਮ ਜੇਐਸ ਗਿੱਟਹਬ ਦੀਆਂ ਉਦਾਹਰਣਾਂ
• ਐਪੀਅਮ ਜੇਐਸ ਗਿੱਟਹਬ ਦੀਆਂ ਉਦਾਹਰਣਾਂ

ਸਮਾਨ ਟੂਲ

• ਕੋਈ ਵੀ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਭਾਸ਼ਾ ਜੋ ਤੁਸੀਂ ਸੇਲੇਨਿਅਮ/ਐਪੀਅਮ ਟੈਸਟਾਂ ਦੇ ਨਾਲ ਜੋੜ ਕੇ ਪਸੰਦ ਕਰਦੇ ਹੋ;
• ਕੋਈ ਵੀ ਟੈਸਟ;
• ਕੋਈ ਵੀ ਟੈਸਟ ਦੌੜਾਕ.

2. ਵਰਜਨ ਕੰਟਰੋਲ ਸਿਸਟਮ (Git)

ਤਕਨਾਲੋਜੀ ਦਾ ਸੰਖੇਪ ਵਰਣਨ

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

ਆਟੋਮੇਸ਼ਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ ਮੁੱਲ

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

ਅਸੀਂ IaC ਨੂੰ ਕਦਮ 7 ਵਿੱਚ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਦੇਖਾਂਗੇ, ਪਰ ਹੁਣ ਵੀ ਤੁਸੀਂ ਇੱਕ ਸਥਾਨਕ ਰਿਪੋਜ਼ਟਰੀ ਬਣਾ ਕੇ ਸਥਾਨਕ ਤੌਰ 'ਤੇ Git ਦੀ ਵਰਤੋਂ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ। ਜਦੋਂ ਅਸੀਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਇੱਕ ਰਿਮੋਟ ਰਿਪੋਜ਼ਟਰੀ ਜੋੜਦੇ ਹਾਂ ਤਾਂ ਵੱਡੀ ਤਸਵੀਰ ਦਾ ਵਿਸਤਾਰ ਕੀਤਾ ਜਾਵੇਗਾ।

ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਦਾ ਚਿੱਤਰ

ਪੜਚੋਲ ਕਰਨ ਲਈ ਲਿੰਕ

• ਵਰਜਨ ਕੰਟਰੋਲ ਕੀ ਹੈ
• ਗਿੱਟ
• ਸ਼ੁਰੂਆਤ ਕਰਨਾ - ਸੰਸਕਰਣ ਨਿਯੰਤਰਣ ਬਾਰੇ

ਸਮਾਨ ਟੂਲ

• SVN
• ਮਰਕੁਰੀਅਲ 
• Microsoft TFS (ਹੁਣ Azure DevOps ਸੇਵਾਵਾਂ ਦਾ ਹਿੱਸਾ ਹੈ)

3. ਕੰਟੇਨਰਾਈਜ਼ੇਸ਼ਨ (ਡੌਕਰ)

ਤਕਨਾਲੋਜੀ ਦਾ ਸੰਖੇਪ ਵਰਣਨ

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

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

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

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

ਆਟੋਮੇਸ਼ਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ ਮੁੱਲ

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

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

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

ਡੌਕਰ ਵਿੱਚ ਸੇਲੇਨਿਅਮ ਗਰਿੱਡ

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

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

ਵੈੱਬ ਲਈ Selenoid

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

ਪਰ, ਹਾਏ, ਸੇਲੇਨੋਇਡ ਅਜੇ ਵੀ ਚਾਂਦੀ ਦੀ ਗੋਲੀ ਨਹੀਂ ਹੈ. ਸਾਨੂੰ 'ਮੰਗ 'ਤੇ ਬ੍ਰਾਊਜ਼ਰ' ਵਿਸ਼ੇਸ਼ਤਾ ਮਿਲੀ ਹੈ, ਪਰ 'ਡਿਮਾਂਡ 'ਤੇ ਸਰੋਤ' ਵਿਸ਼ੇਸ਼ਤਾ ਅਜੇ ਵੀ ਉਪਲਬਧ ਨਹੀਂ ਹੈ। ਸੇਲੇਨੋਇਡ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਇਸਨੂੰ ਭੌਤਿਕ ਹਾਰਡਵੇਅਰ ਜਾਂ ਇੱਕ VM 'ਤੇ ਤੈਨਾਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਾਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿੰਨੇ ਸਰੋਤ ਨਿਰਧਾਰਤ ਕੀਤੇ ਜਾਣੇ ਹਨ। ਮੇਰਾ ਅਨੁਮਾਨ ਹੈ ਕਿ ਇਹ ਛੋਟੇ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ ਜੋ ਸਮਾਨਾਂਤਰ ਵਿੱਚ 10, 20 ਜਾਂ ਇੱਥੋਂ ਤੱਕ ਕਿ 30 ਬ੍ਰਾਉਜ਼ਰ ਚਲਾਉਂਦੇ ਹਨ। ਪਰ ਕੀ ਜੇ ਸਾਨੂੰ 100, 500, 1000 ਅਤੇ ਹੋਰ ਦੀ ਲੋੜ ਹੈ? ਇੰਨੇ ਸਾਰੇ ਸਰੋਤਾਂ ਨੂੰ ਹਰ ਸਮੇਂ ਕਾਇਮ ਰੱਖਣ ਅਤੇ ਭੁਗਤਾਨ ਕਰਨ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੁੰਦਾ. ਇਸ ਲੇਖ ਦੇ ਸੈਕਸ਼ਨ 5 ਅਤੇ 6 ਵਿੱਚ, ਅਸੀਂ ਉਹਨਾਂ ਹੱਲਾਂ ਬਾਰੇ ਚਰਚਾ ਕਰਾਂਗੇ ਜੋ ਤੁਹਾਨੂੰ ਸਕੇਲ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਕੰਪਨੀ ਦੀਆਂ ਲਾਗਤਾਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਕਮੀ ਆਉਂਦੀ ਹੈ।

ਐਂਡਰੌਇਡ ਲਈ ਸੇਲੇਨੋਇਡ

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

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

ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਦਾ ਚਿੱਤਰ

ਇਸ ਲੇਖ ਦੇ ਸੰਦਰਭ ਵਿੱਚ, ਅਸੀਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਦਰਸਾਉਣ ਲਈ 2 ਟੂਲ ਜੋੜਾਂਗੇ। ਇਹ ਵੈੱਬ ਟੈਸਟਾਂ ਲਈ ਸੇਲੇਨੀਅਮ ਗਰਿੱਡ ਅਤੇ ਐਂਡਰਾਇਡ ਟੈਸਟਾਂ ਲਈ ਸੇਲੇਨੌਇਡ ਹਨ। GitHub ਟਿਊਟੋਰਿਅਲ ਵਿੱਚ, ਮੈਂ ਤੁਹਾਨੂੰ ਇਹ ਵੀ ਦਿਖਾਵਾਂਗਾ ਕਿ ਵੈੱਬ ਟੈਸਟਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਸੇਲੇਨੋਇਡ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਨੀ ਹੈ। 

ਪੜਚੋਲ ਕਰਨ ਲਈ ਲਿੰਕ

• ਡੌਕਰ: ਕੀ ਕੰਟੇਨਰ ਹੈ
• ਡੌਕਰ: ਸ਼ੁਰੂ ਕਰੋ
• ਡੌਕਰ ਲਈ 5 ਕੰਟੇਨਰ ਵਿਕਲਪ
• ਸੇਲੇਨੀਅਮ ਗਰਿੱਡ
• ਸੇਲੇਨਿਅਮ ਡੌਕਰ
• ਸੇਲੇਨੋਇਡ
• ਸੇਲੇਨੋਇਡ ਗਿਥਬ
• ਐਂਡਰੌਇਡ ਇਮੂਲੇਟਰਾਂ ਲਈ KVM ਸੈੱਟਅੱਪ
• ਡੌਕਰ ਡੀਪ ਡਾਈਵ ਕਿਤਾਬ

ਸਮਾਨ ਟੂਲ

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

4.CI/CD

ਤਕਨਾਲੋਜੀ ਦਾ ਸੰਖੇਪ ਵਰਣਨ

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

ਇਸ ਲਈ, ਇੱਥੇ 3 ਸ਼ਰਤਾਂ ਹਨ: CI - ਨਿਰੰਤਰ ਏਕੀਕਰਣ, CD - ਨਿਰੰਤਰ ਡਿਲਿਵਰੀ ਅਤੇ ਦੁਬਾਰਾ CD - ਨਿਰੰਤਰ ਤੈਨਾਤੀ। (ਹੇਠਾਂ ਮੈਂ ਇਹਨਾਂ ਸ਼ਬਦਾਂ ਦੀ ਵਰਤੋਂ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਕਰਾਂਗਾ). ਹਰੇਕ ਸੋਧ ਤੁਹਾਡੀ ਵਿਕਾਸ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਕਈ ਵਾਧੂ ਕਦਮ ਜੋੜਦੀ ਹੈ। ਪਰ ਸ਼ਬਦ ਲਗਾਤਾਰ (ਲਗਾਤਾਰ) ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ ਹੈ। ਇਸ ਸੰਦਰਭ ਵਿੱਚ, ਸਾਡਾ ਮਤਲਬ ਹੈ ਕੁਝ ਅਜਿਹਾ ਜੋ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ, ਬਿਨਾਂ ਕਿਸੇ ਰੁਕਾਵਟ ਜਾਂ ਦਸਤੀ ਦਖਲ ਦੇ ਵਾਪਰਦਾ ਹੈ। ਆਓ ਇਸ ਸੰਦਰਭ ਵਿੱਚ CI & CD ਅਤੇ CD ਨੂੰ ਵੇਖੀਏ.

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

ਆਟੋਮੇਸ਼ਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ ਮੁੱਲ

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

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

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

ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਦਾ ਚਿੱਤਰ

ਪੜਚੋਲ ਕਰਨ ਲਈ ਲਿੰਕ

• ਮਾਰਟਿਨ ਫੋਲਰ: ਨਿਰੰਤਰ ਏਕੀਕਰਣ
• GitLab CI/CD
• ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਕਿਤਾਬ
• ਨਿਰੰਤਰ ਡਿਲਿਵਰੀ ਕਿਤਾਬ

ਸਮਾਨ ਟੂਲ

• ਜੇਨਕਿੰਸ
• ਟੀਮਸਿਟੀ
• ਟ੍ਰੇਵਿਸ 
• ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੇ

5. ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ

ਤਕਨਾਲੋਜੀ ਦਾ ਸੰਖੇਪ ਵਰਣਨ

ਇਸ ਭਾਗ ਵਿੱਚ ਅਸੀਂ 'ਪਬਲਿਕ ਕਲਾਉਡਸ' ਨਾਮਕ ਇੱਕ ਪ੍ਰਸਿੱਧ ਰੁਝਾਨ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ। ਉੱਪਰ ਦੱਸੇ ਗਏ ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਅਤੇ ਕੰਟੇਨਰਾਈਜ਼ੇਸ਼ਨ ਤਕਨਾਲੋਜੀਆਂ ਦੇ ਬਹੁਤ ਸਾਰੇ ਲਾਭਾਂ ਦੇ ਬਾਵਜੂਦ, ਸਾਨੂੰ ਅਜੇ ਵੀ ਕੰਪਿਊਟਿੰਗ ਸਰੋਤਾਂ ਦੀ ਲੋੜ ਹੈ। ਕੰਪਨੀਆਂ ਮਹਿੰਗੇ ਸਰਵਰ ਖਰੀਦਦੀਆਂ ਹਨ ਜਾਂ ਡੇਟਾ ਸੈਂਟਰਾਂ ਨੂੰ ਕਿਰਾਏ 'ਤੇ ਲੈਂਦੀਆਂ ਹਨ, ਪਰ ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਸਾਨੂੰ ਕਿੰਨੇ ਸਰੋਤਾਂ ਦੀ ਲੋੜ ਪਵੇਗੀ, ਕੀ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ 24/7 ਅਤੇ ਕਿਹੜੇ ਉਦੇਸ਼ਾਂ ਲਈ ਵਰਤਾਂਗੇ, ਇਸਦੀ ਗਣਨਾ (ਕਈ ਵਾਰ ਗੈਰ-ਯਥਾਰਥਵਾਦੀ) ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਉਤਪਾਦਨ ਲਈ XNUMX/XNUMX ਚੱਲ ਰਹੇ ਸਰਵਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਪਰ ਕੀ ਸਾਨੂੰ ਕੰਮ ਦੇ ਘੰਟਿਆਂ ਤੋਂ ਬਾਹਰ ਟੈਸਟ ਕਰਨ ਲਈ ਸਮਾਨ ਸਰੋਤਾਂ ਦੀ ਲੋੜ ਹੈ? ਇਹ ਟੈਸਟਿੰਗ ਦੀ ਕਿਸਮ 'ਤੇ ਵੀ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਇੱਕ ਉਦਾਹਰਨ ਲੋਡ/ਤਣਾਅ ਦੇ ਟੈਸਟ ਹੋਣਗੇ ਜੋ ਅਸੀਂ ਅਗਲੇ ਦਿਨ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਗੈਰ-ਕੰਮ ਦੇ ਘੰਟਿਆਂ ਦੌਰਾਨ ਚਲਾਉਣ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹਾਂ। ਪਰ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ XNUMX/XNUMX ਸਰਵਰ ਦੀ ਉਪਲਬਧਤਾ ਅੰਤ-ਤੋਂ-ਅੰਤ ਆਟੋਮੇਟਿਡ ਟੈਸਟਾਂ ਲਈ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ ਮੈਨੂਅਲ ਟੈਸਟਿੰਗ ਵਾਤਾਵਰਣਾਂ ਲਈ ਨਹੀਂ। ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਲਈ, ਮੰਗ 'ਤੇ ਲੋੜ ਅਨੁਸਾਰ ਲੋੜੀਂਦੇ ਸਰੋਤਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ, ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ, ਅਤੇ ਉਹਨਾਂ ਦੀ ਲੋੜ ਨਾ ਹੋਣ 'ਤੇ ਭੁਗਤਾਨ ਕਰਨਾ ਬੰਦ ਕਰਨਾ ਚੰਗਾ ਹੋਵੇਗਾ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕੁਝ ਮਾਊਸ ਕਲਿੱਕ ਕਰਕੇ ਜਾਂ ਕੁਝ ਸਕ੍ਰਿਪਟਾਂ ਚਲਾ ਕੇ ਉਹਨਾਂ ਨੂੰ ਤੁਰੰਤ ਪ੍ਰਾਪਤ ਕਰਨਾ ਬਹੁਤ ਵਧੀਆ ਹੋਵੇਗਾ। ਇਸ ਲਈ ਜਨਤਕ ਬੱਦਲਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਆਓ ਪਰਿਭਾਸ਼ਾ ਨੂੰ ਵੇਖੀਏ:

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

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

ਆਟੋਮੇਸ਼ਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ ਮੁੱਲ

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

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

ਆਟੋਮੇਸ਼ਨ ਦੇ ਉਦੇਸ਼ਾਂ ਲਈ GCP ਬਨਾਮ ਸੌਸ ਲੈਬ:

ਚਲੋ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਸਾਨੂੰ ਇੱਕੋ ਸਮੇਂ 8 ਵੈੱਬ ਟੈਸਟ ਅਤੇ 8 ਐਂਡਰਾਇਡ ਟੈਸਟ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਇਸਦੇ ਲਈ ਅਸੀਂ GCP ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ ਅਤੇ Selenoid ਨਾਲ 2 ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਚਲਾਵਾਂਗੇ। ਪਹਿਲੇ ਇੱਕ 'ਤੇ ਅਸੀਂ ਬ੍ਰਾਉਜ਼ਰ ਦੇ ਨਾਲ 8 ਕੰਟੇਨਰਾਂ ਨੂੰ ਵਧਾਵਾਂਗੇ। ਦੂਜੇ 'ਤੇ ਇਮੂਲੇਟਰਾਂ ਵਾਲੇ 8 ਕੰਟੇਨਰ ਹਨ। ਆਓ ਕੀਮਤਾਂ 'ਤੇ ਇੱਕ ਨਜ਼ਰ ਮਾਰੀਏ:  

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

ਅਤੇ ਇੱਥੇ ਸੌਸ ਲੈਬਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਟੈਰਿਫ ਹਨ:

ਮੇਰਾ ਮੰਨਣਾ ਹੈ ਕਿ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਅੰਤਰ ਦੇਖਿਆ ਹੈ, ਪਰ ਮੈਂ ਅਜੇ ਵੀ ਸਾਡੇ ਕੰਮ ਲਈ ਗਣਨਾਵਾਂ ਦੇ ਨਾਲ ਇੱਕ ਸਾਰਣੀ ਪ੍ਰਦਾਨ ਕਰਾਂਗਾ:

ਲੋੜੀਂਦੇ ਸਰੋਤ
ਮਾਂਟਲੀ
ਕੰਮ ਦੇ ਘੰਟੇ(8am - 8pm)
ਕੰਮ ਦੇ ਘੰਟੇ+ ਅਗਾਊਂ

ਵੈੱਬ ਲਈ GCP
n1-ਸਟੈਂਡਰਡ-1 x 8 = n1-ਸਟੈਂਡਰਡ-8
$194.18
23 ਦਿਨ * 12 ਘੰਟੇ * 0.38 = $104.88 
23 ਦਿਨ * 12 ਘੰਟੇ * 0.08 = $22.08

ਵੈੱਬ ਲਈ ਸੌਸ ਲੈਬ
ਵਰਚੁਅਲ Cloud8 ਸਮਾਨਾਂਤਰ ਟੈਸਟ
$1.559
-
-

Android ਲਈ GCP
n1-ਸਟੈਂਡਰਡ-4 x 8: n1-ਸਟੈਂਡਰਡ-16
$776.72
23 ਦਿਨ * 12 ਘੰਟੇ * 1.52 = $419.52 
23 ਦਿਨ * 12 ਘੰਟੇ * 0.32 = $88.32

ਐਂਡਰੌਇਡ ਲਈ ਸੌਸ ਲੈਬ
ਰੀਅਲ ਡਿਵਾਈਸ ਕਲਾਉਡ 8 ਪੈਰਲਲ ਟੈਸਟ
$1.999
-
-

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

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

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

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

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

ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਦਾ ਚਿੱਤਰ

ਪੜਚੋਲ ਕਰਨ ਲਈ ਲਿੰਕ

• ਜੀ.ਸੀ.ਪੀ.
• GCP: ਅਗਾਊਂ
• GCP: VM ਕੀਮਤ
• ਸੌਸਲੈਬਸ
• ਕਲਾਉਡ ਪ੍ਰਦਾਤਾਵਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨਾ

ਸਮਾਨ ਟੂਲ:

• ਪ੍ਰਸਥਿਤੀ 
• ਅਜ਼ੁਰ

6. ਆਰਕੈਸਟਰਾ

ਤਕਨਾਲੋਜੀ ਦਾ ਸੰਖੇਪ ਵਰਣਨ

ਮੇਰੇ ਕੋਲ ਚੰਗੀ ਖ਼ਬਰ ਹੈ - ਅਸੀਂ ਲਗਭਗ ਲੇਖ ਦੇ ਅੰਤ 'ਤੇ ਹਾਂ! ਇਸ ਸਮੇਂ, ਸਾਡੇ ਆਟੋਮੇਸ਼ਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਵੈੱਬ ਅਤੇ ਐਂਡਰੌਇਡ ਟੈਸਟ ਸ਼ਾਮਲ ਹਨ, ਜੋ ਅਸੀਂ ਡੌਕਰ-ਸਮਰੱਥ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਸਮਾਨਾਂਤਰ ਵਿੱਚ GitLab CI ਦੁਆਰਾ ਚਲਾਉਂਦੇ ਹਾਂ: ਸੇਲੇਨਿਅਮ ਗਰਿੱਡ ਅਤੇ ਸੇਲੇਨੋਇਡ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਬ੍ਰਾਊਜ਼ਰਾਂ ਅਤੇ ਇਮੂਲੇਟਰਾਂ ਵਾਲੇ ਕੰਟੇਨਰਾਂ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਨ ਲਈ GCP ਰਾਹੀਂ ਬਣਾਈਆਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਲਾਗਤਾਂ ਨੂੰ ਘਟਾਉਣ ਲਈ, ਅਸੀਂ ਇਹਨਾਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਨੂੰ ਸਿਰਫ ਮੰਗ 'ਤੇ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ ਅਤੇ ਜਦੋਂ ਟੈਸਟਿੰਗ ਨਹੀਂ ਕੀਤੀ ਜਾ ਰਹੀ ਹੁੰਦੀ ਹੈ ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਬੰਦ ਕਰਦੇ ਹਾਂ। ਕੀ ਕੋਈ ਹੋਰ ਚੀਜ਼ ਹੈ ਜੋ ਸਾਡੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਸੁਧਾਰ ਸਕਦੀ ਹੈ? ਜਵਾਬ ਹਾਂ ਹੈ! Kubernetes (K8s) ਨੂੰ ਮਿਲੋ!

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

ਅਸਲ ਵਿੱਚ, ਕੁਬਰਨੇਟਸ ਨੂੰ ਸਕ੍ਰੈਚ ਤੋਂ ਹੱਥੀਂ ਤੈਨਾਤ ਕਰਨਾ ਕੋਈ ਮਾਮੂਲੀ ਕੰਮ ਨਹੀਂ ਹੈ। ਮੈਂ ਮਸ਼ਹੂਰ ਗਾਈਡ "ਕੁਬਰਨੇਟਸ ਦ ਹਾਰਡ ਵੇ" ਲਈ ਇੱਕ ਲਿੰਕ ਛੱਡਾਂਗਾ ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਸਦਾ ਅਭਿਆਸ ਕਰ ਸਕਦੇ ਹੋ। ਪਰ, ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਵਿਕਲਪਕ ਤਰੀਕੇ ਅਤੇ ਸਾਧਨ ਹਨ. ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਹੈ GCP ਵਿੱਚ Google Kubernetes Engine (GKE) ਦੀ ਵਰਤੋਂ ਕਰਨਾ, ਜੋ ਤੁਹਾਨੂੰ ਕੁਝ ਕਲਿੱਕਾਂ ਵਿੱਚ ਇੱਕ ਰੈਡੀਮੇਡ ਕਲੱਸਟਰ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ। ਮੈਂ ਸਿੱਖਣਾ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਇਸ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦਾ ਹਾਂ, ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਨੂੰ ਇਹ ਸਿੱਖਣ ਦੀ ਬਜਾਏ ਕਿ ਅੰਦਰੂਨੀ ਭਾਗਾਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਨਾਲ ਕਿਵੇਂ ਜੋੜਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਆਪਣੇ ਕੰਮਾਂ ਲਈ K8s ਦੀ ਵਰਤੋਂ ਕਰਨ ਬਾਰੇ ਸਿੱਖਣ 'ਤੇ ਧਿਆਨ ਦੇਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ। 

ਆਟੋਮੇਸ਼ਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ ਮੁੱਲ

ਆਓ ਕੁਝ ਮਹੱਤਵਪੂਰਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ 'ਤੇ ਇੱਕ ਨਜ਼ਰ ਮਾਰੀਏ ਜੋ K8s ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ:

• ਐਪਲੀਕੇਸ਼ਨ ਡਿਪਲਾਇਮੈਂਟ: VMs ਦੀ ਬਜਾਏ ਮਲਟੀ-ਨੋਡ ਕਲੱਸਟਰ ਦੀ ਵਰਤੋਂ ਕਰਨਾ;
• ਗਤੀਸ਼ੀਲ ਸਕੇਲਿੰਗ: ਸਰੋਤਾਂ ਦੀ ਲਾਗਤ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਜੋ ਸਿਰਫ ਮੰਗ 'ਤੇ ਵਰਤੇ ਜਾਂਦੇ ਹਨ;
• ਸਵੈ-ਇਲਾਜ: ਪੌਡਾਂ ਦੀ ਆਟੋਮੈਟਿਕ ਰਿਕਵਰੀ (ਜਿਸ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਕੰਟੇਨਰ ਵੀ ਬਹਾਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ);
• ਅੱਪਡੇਟ ਦਾ ਰੋਲਆਊਟ ਅਤੇ ਡਾਊਨਟਾਈਮ ਤੋਂ ਬਿਨਾਂ ਤਬਦੀਲੀਆਂ ਦਾ ਰੋਲਬੈਕ: ਟੂਲਸ, ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਇਮੂਲੇਟਰਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ ਮੌਜੂਦਾ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਕੰਮ ਵਿੱਚ ਵਿਘਨ ਨਹੀਂ ਪਾਉਂਦਾ ਹੈ

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

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

ਆਉ ਹੁਣ ਉਪਰੋਕਤ ਸ਼ਰਤਾਂ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਸਾਡੇ ਸਾਧਨਾਂ ਨੂੰ ਵੇਖੀਏ।

ਸੇਲੇਨਿਅਮ ਗਰਿੱਡ

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

ਸੇਲੇਨੋਇਡ:

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

ਚੰਦ:

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

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

ਇਸ ਲਈ, ਚੰਦਰਮਾ ਇੱਕ ਵਧੀਆ ਹੱਲ ਹੈ, ਪਰ ਇੱਕ ਸਮੱਸਿਆ ਹੈ: ਇਹ ਮੁਫਤ ਨਹੀਂ ਹੈ. ਕੀਮਤ ਸੈਸ਼ਨਾਂ ਦੀ ਗਿਣਤੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ. ਤੁਸੀਂ ਸਿਰਫ਼ 0-4 ਸੈਸ਼ਨ ਮੁਫ਼ਤ ਵਿੱਚ ਚਲਾ ਸਕਦੇ ਹੋ, ਜੋ ਕਿ ਖਾਸ ਤੌਰ 'ਤੇ ਉਪਯੋਗੀ ਨਹੀਂ ਹੈ। ਪਰ, ਪੰਜਵੇਂ ਸੈਸ਼ਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋਏ, ਤੁਹਾਨੂੰ ਹਰੇਕ ਲਈ $5 ਦਾ ਭੁਗਤਾਨ ਕਰਨਾ ਪਵੇਗਾ। ਸਥਿਤੀ ਕੰਪਨੀ ਤੋਂ ਵੱਖਰੀ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਚੰਦਰਮਾ ਦੀ ਵਰਤੋਂ ਬੇਕਾਰ ਹੈ. ਜਿਵੇਂ ਕਿ ਮੈਂ ਉੱਪਰ ਦੱਸਿਆ ਹੈ, ਅਸੀਂ ਮੰਗ 'ਤੇ ਸੇਲੇਨਿਅਮ ਗਰਿੱਡ ਨਾਲ VM ਚਲਾ ਸਕਦੇ ਹਾਂ ਜਾਂ ਕਲੱਸਟਰ ਵਿੱਚ ਨੋਡਾਂ ਦੀ ਗਿਣਤੀ ਵਧਾ ਸਕਦੇ ਹਾਂ। ਲਗਭਗ ਇੱਕ ਪਾਈਪਲਾਈਨ ਲਈ, ਅਸੀਂ 500 ਬ੍ਰਾਊਜ਼ਰ ਲਾਂਚ ਕਰਦੇ ਹਾਂ ਅਤੇ ਟੈਸਟਾਂ ਦੇ ਪੂਰੇ ਹੋਣ ਤੋਂ ਬਾਅਦ ਸਾਰੇ ਸਰੋਤ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਾਂ। ਜੇਕਰ ਅਸੀਂ ਚੰਦਰਮਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਇੱਕ ਵਾਧੂ 500 x 5 = $2500 ਪ੍ਰਤੀ ਮਹੀਨਾ ਭੁਗਤਾਨ ਕਰਨਾ ਪਵੇਗਾ, ਭਾਵੇਂ ਅਸੀਂ ਕਿੰਨੀ ਵਾਰ ਟੈਸਟਾਂ ਨੂੰ ਚਲਾਉਂਦੇ ਹਾਂ। ਦੁਬਾਰਾ ਫਿਰ, ਮੈਂ ਇਹ ਨਹੀਂ ਕਹਿ ਰਿਹਾ ਕਿ ਚੰਦਰਮਾ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ। ਤੁਹਾਡੇ ਕੰਮਾਂ ਲਈ, ਇਹ ਇੱਕ ਲਾਜ਼ਮੀ ਹੱਲ ਹੋ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਤੁਹਾਡੀ ਸੰਸਥਾ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟ/ਟੀਮਾਂ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ ਹਰੇਕ ਲਈ ਇੱਕ ਵਿਸ਼ਾਲ ਸਾਂਝੇ ਕਲੱਸਟਰ ਦੀ ਲੋੜ ਹੈ। ਹਮੇਸ਼ਾਂ ਵਾਂਗ, ਮੈਂ ਅੰਤ ਵਿੱਚ ਇੱਕ ਲਿੰਕ ਛੱਡਦਾ ਹਾਂ ਅਤੇ ਤੁਹਾਡੇ ਕੰਮ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਸਾਰੀਆਂ ਲੋੜੀਂਦੀਆਂ ਗਣਨਾਵਾਂ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ।

ਕਾਲੀਸਟੋ:(ਧਿਆਨ ਦਿਓ! ਇਹ ਮੂਲ ਲੇਖ ਵਿੱਚ ਨਹੀਂ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਰੂਸੀ ਅਨੁਵਾਦ ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ)

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

ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਦਾ ਚਿੱਤਰ

ਪੜਚੋਲ ਕਰਨ ਲਈ ਲਿੰਕ

• ਕੁਬਰਨੇਟਸ: ਸੈੱਟਅੱਪ
• ਕੁਬਰਨੇਟਸ: ਔਖਾ ਤਰੀਕਾ
• ਕੁਬਰਨੇਟਸ: ਸੇਲੇਨਿਅਮ
• GCP: ਕੁਬਰਨੇਟਸ ਇੰਜਣ
• ਚੰਦ
• ਕੁਬਰਨੇਟਸ ਬੁੱਕ
• ਕੁਬਰਨੇਟਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਵੰਡਿਆ ਆਟੋਮੇਸ਼ਨ
• ਸੇਲੇਨਿਅਮ ਗਰਿੱਡ 4
• Callisto GitHub
• Wrike TechClub (ਕੈਲਿਸਟੋ)

ਸਮਾਨ ਟੂਲ

• ਡੌਕਰ ਦਾ ਝੁੰਡ 
• ਮੈਰਾਥਨ 

7. ਕੋਡ (IaC) ਵਜੋਂ ਬੁਨਿਆਦੀ ਢਾਂਚਾ

ਤਕਨਾਲੋਜੀ ਦਾ ਸੰਖੇਪ ਵਰਣਨ

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

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

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

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

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

ਆਟੋਮੇਸ਼ਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ ਮੁੱਲ

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

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

1. ਟੈਰਾਫਾਰਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ VM ਅਤੇ ਕਲੱਸਟਰਾਂ ਦੀਆਂ ਜ਼ਰੂਰੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਮਾਪਦੰਡਾਂ ਦਾ ਵਰਣਨ ਕਰੋ।

2. Ansible ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਟੈਸਟਿੰਗ ਲਈ ਲੋੜੀਂਦੇ ਟੂਲ ਸਥਾਪਤ ਕਰੋ: ਡੌਕਰ, ਸੇਲੇਨੋਇਡ, ਸੇਲੇਨਿਅਮ ਗਰਿੱਡ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰਾਂ/ਇਮੂਲੇਟਰਾਂ ਦੇ ਲੋੜੀਂਦੇ ਸੰਸਕਰਣਾਂ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰੋ।

3. ਟੈਰਾਫਾਰਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, VM ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਵਰਣਨ ਕਰੋ ਜਿਸ ਵਿੱਚ GitLab ਰਨਰ ਲਾਂਚ ਕੀਤਾ ਜਾਵੇਗਾ।

4. Ansible, ਸੈੱਟ ਸੈਟਿੰਗਾਂ ਅਤੇ ਕੌਂਫਿਗਰੇਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ GitLab ਰਨਰ ਅਤੇ ਲੋੜੀਂਦੇ ਸਹਾਇਕ ਟੂਲ ਸਥਾਪਤ ਕਰੋ।

ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਦਾ ਚਿੱਤਰ

ਪੜਚੋਲ ਕਰਨ ਲਈ ਲਿੰਕ:

• ਟੈਰਾਫਾਰਮ
• Ansimate
• ਜਵਾਬਦੇਹ ਅਤੇ ਟੈਰਾਫਾਰਮ ਇਕੱਠੇ ਬਿਹਤਰ
• ਟੈਰਾਫਾਰਮ ਲਈ ਇੱਕ ਵਿਆਪਕ ਗਾਈਡ
• ਅਸੀਂ ਟੈਰਾਫਾਰਮ ਦੀ ਵਰਤੋਂ ਕਿਉਂ ਕਰਦੇ ਹਾਂ ਨਾ ਕਿ ਸ਼ੈੱਫ, ਕਠਪੁਤਲੀ, ਜਵਾਬਦੇਹ, ਸਾਲਟਸਟੈਕ, ਜਾਂ ਕਲਾਉਡਫਾਰਮੇਸ਼ਨ
• GCP: IaC

ਸਮਾਨ ਟੂਲ

• ਸਿਰ '
• ਕਠਪੁਤਲੀ
• ਸਾਲਟਸਟੈਕ
• ਭਟਕਣਾ

ਆਓ ਇਸਦਾ ਸਾਰ ਕਰੀਏ!

ਕਦਮ
ਤਕਨਾਲੋਜੀ
ਸੰਦ
ਆਟੋਮੇਸ਼ਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ ਮੁੱਲ

1
ਸਥਾਨਕ ਚੱਲ ਰਿਹਾ ਹੈ
Node.js, Selenium, Appium

• ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਲਈ ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ ਟੂਲ
• ਬਹੁਤ ਸਾਰੀਆਂ ਭਾਸ਼ਾਵਾਂ ਅਤੇ ਪਲੇਟਫਾਰਮਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ (Node.js ਸਮੇਤ)

2
ਸੰਸਕਰਣ ਕੰਟਰੋਲ ਸਿਸਟਮ 
ਗਿੱਟ

• ਵਿਕਾਸ ਕੋਡ ਦੇ ਨਾਲ ਮਿਲਦੇ-ਜੁਲਦੇ ਲਾਭ

3
ਕੰਟੇਨਰਾਈਜ਼ੇਸ਼ਨ
ਡੌਕਰ, ਸੇਲੇਨਿਅਮ ਗਰਿੱਡ, ਸੇਲੇਨੋਇਡ (ਵੈੱਬ, ਐਂਡਰੌਇਡ)

• ਸਮਾਂਤਰ ਵਿੱਚ ਟੈਸਟ ਚੱਲ ਰਿਹਾ ਹੈ
• ਅਲੱਗ-ਥਲੱਗ ਵਾਤਾਵਰਣ
• ਸਧਾਰਨ, ਲਚਕਦਾਰ ਵਰਜਨ ਅੱਪਗਰੇਡ
• ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਅਣਵਰਤੇ ਸਰੋਤਾਂ ਨੂੰ ਰੋਕ ਰਿਹਾ ਹੈ
• ਸਥਾਪਤ ਕਰਨਾ ਆਸਾਨ ਹੈ

4
CI/CD
ਗਿਟਲੈਬ ਸੀ.ਆਈ

• ਪਾਈਪਲਾਈਨ ਦੇ ਹਿੱਸੇ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ
• ਤੇਜ਼ ਫੀਡਬੈਕ
• ਪੂਰੀ ਕੰਪਨੀ/ਟੀਮ ਲਈ ਦਰਿਸ਼ਗੋਚਰਤਾ

5
ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ
Google ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ

• ਮੰਗ 'ਤੇ ਸਰੋਤ (ਅਸੀਂ ਸਿਰਫ਼ ਲੋੜ ਪੈਣ 'ਤੇ ਭੁਗਤਾਨ ਕਰਦੇ ਹਾਂ)
• ਪ੍ਰਬੰਧਨ ਅਤੇ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਆਸਾਨ
• ਸਾਰੇ ਸਰੋਤਾਂ ਦੀ ਦਿੱਖ ਅਤੇ ਨਿਯੰਤਰਣ

6
ਆਰਕੈਸਟਰੇਸ਼ਨ
ਕਬਰਨੇਟਿਸ
ਪੌਡਾਂ ਦੇ ਅੰਦਰ ਬ੍ਰਾਊਜ਼ਰ/ਇਮੂਲੇਟਰਾਂ ਵਾਲੇ ਕੰਟੇਨਰਾਂ ਦੇ ਸੰਦਰਭ ਵਿੱਚ:

• ਸਕੇਲਿੰਗ/ਆਟੋ ਸਕੇਲਿੰਗ
• ਸਵੈ-ਇਲਾਜ
• ਬਿਨਾਂ ਕਿਸੇ ਰੁਕਾਵਟ ਦੇ ਅੱਪਡੇਟ ਅਤੇ ਰੋਲਬੈਕ

7
ਇੱਕ ਕੋਡ (IaC) ਦੇ ਰੂਪ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚਾ
ਟੈਰਾਫਾਰਮ, ਜਵਾਬਦੇਹ

• ਵਿਕਾਸ ਦੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਨਾਲ ਮਿਲਦੇ-ਜੁਲਦੇ ਲਾਭ
• ਕੋਡ ਸੰਸਕਰਣ ਦੇ ਸਾਰੇ ਫਾਇਦੇ
• ਤਬਦੀਲੀਆਂ ਕਰਨ ਅਤੇ ਸੰਭਾਲਣ ਲਈ ਆਸਾਨ
• ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਵੈਚਾਲਿਤ

ਦਿਮਾਗ ਦਾ ਨਕਸ਼ਾ ਚਿੱਤਰ: ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਵਿਕਾਸ

ਕਦਮ 1: ਸਥਾਨਕ

ਕਦਮ 2: VCS

ਕਦਮ 3: ਕੰਟੇਨਰਾਈਜ਼ੇਸ਼ਨ 

ਕਦਮ 4: CI/CD 

ਕਦਮ 5: ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ

ਕਦਮ 6: ਆਰਕੈਸਟਰੇਸ਼ਨ

ਕਦਮ 7: ਆਈਏਸੀ

ਅੱਗੇ ਕੀ ਹੈ?

ਇਸ ਲਈ, ਇਹ ਲੇਖ ਦਾ ਅੰਤ ਹੈ. ਪਰ ਅੰਤ ਵਿੱਚ, ਮੈਂ ਤੁਹਾਡੇ ਨਾਲ ਕੁਝ ਸਮਝੌਤੇ ਸਥਾਪਤ ਕਰਨਾ ਚਾਹਾਂਗਾ।

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

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

ਮੇਰੇ ਪਾਸੇ ਤੋਂ

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

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

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

ਸਰੋਤ: www.habr.com