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

ਇਹ ਮੇਰੀ ਪ੍ਰਤੀਲਿਪੀ ਹੈ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ DevopsConf 2019-05-28.

ਸਲਾਈਡਾਂ ਅਤੇ ਵੀਡੀਓਜ਼

ਅੰਗਰੇਜ਼ੀ ਵਰਜਨ
ਰਸ਼ੀਅਨ ਸੰਸਕਰਣ
ਡਰਾਈ ਰਨ 2019-04-24 SpbLUG
DevopsConf 2019-05-28 ਤੋਂ ਵੀਡੀਓ(RU)
DINS DevOps ਸ਼ਾਮ 2019-06-20 ਤੋਂ ਵੀਡੀਓ(RU)
ਸਲਾਇਡ

ਬਾਸ਼ ਇਤਿਹਾਸ ਦੇ ਰੂਪ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚਾ

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

ਕੁਝ ਇੱਛਾ ਨਾਲ, ਅਸੀਂ ਇਹ ਕਹਿ ਸਕਦੇ ਹਾਂ ਬਾਸ਼ ਇਤਿਹਾਸ ਦੇ ਰੂਪ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਇਹ ਕੋਡ ਵਰਗਾ ਹੈ:

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

ਮੈਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

ਕੋਡ ਦੇ ਤੌਰ 'ਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚਾ

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

ਸੁੱਕਾ

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

ਇੱਥੇ ssh ਰਾਹੀਂ ਲਾਗਇਨ ਕਰੋ ਅਤੇ ਕਮਾਂਡ ਚਲਾਓ।
ਉੱਥੇ ਫਾਇਲ ਨੂੰ ਕਾਪੀ ਕਰੋ.
ਇੱਥੇ ਸੰਰਚਨਾ ਨੂੰ ਠੀਕ ਕਰੋ।
ਉੱਥੇ ਸੇਵਾ ਸ਼ੁਰੂ ਕਰੋ
...
ਲਾਭ!

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

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

CFM ਲਈ ਠੋਸ

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

ਸਿੰਗਲ ਜ਼ਿੰਮੇਵਾਰੀ ਸਿਧਾਂਤ

ਹਰ ਕਲਾਸ ਸਿਰਫ਼ ਇੱਕ ਕੰਮ ਕਰਦੀ ਹੈ।

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

ਖੁੱਲਾ ਬੰਦ ਸਿਧਾਂਤ

ਖੁੱਲ੍ਹਾ/ਬੰਦ ਸਿਧਾਂਤ।

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

ਸ਼ੁਰੂ ਵਿੱਚ, ਅਸੀਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ 'ਤੇ ਟੈਸਟ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਤੈਨਾਤ ਕੀਤਾ, ਪਰ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ ਤੈਨਾਤੀ ਦਾ ਵਪਾਰਕ ਤਰਕ ਲਾਗੂ ਕਰਨ ਤੋਂ ਵੱਖਰਾ ਸੀ, ਅਸੀਂ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਬੇਅਰਮੇਟਲ ਵਿੱਚ ਰੋਲਿੰਗ ਆਊਟ ਸ਼ਾਮਲ ਕੀਤਾ।

ਲਿਸਕੋਵ ਬਦਲੀ ਦਾ ਸਿਧਾਂਤ

ਬਾਰਬਰਾ ਲਿਸਕੋਵ ਦੇ ਬਦਲ ਦਾ ਸਿਧਾਂਤ। ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਵਸਤੂਆਂ ਨੂੰ ਪ੍ਰੋਗਰਾਮ ਦੇ ਸਹੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਉਹਨਾਂ ਦੀਆਂ ਉਪ-ਕਿਸਮਾਂ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਨਾਲ ਬਦਲਣਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

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

ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਟੀਮ ਦੇ ਅੰਦਰ ਇੱਕ ਸਮਝੌਤਾ ਹੈ ਕਿ ਜੇਕਰ ਅਸੀਂ imbjava ਜਾਂ oraclejava ਰੋਲ ਨੂੰ ਸਥਾਪਿਤ ਕੀਤਾ ਹੈ, ਤਾਂ ਸਾਡੇ ਕੋਲ ਇੱਕ ਜਾਵਾ ਬਾਈਨਰੀ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਹੈ। ਇਹ ਜ਼ਰੂਰੀ ਹੈ ਕਿਉਂਕਿ ਅੱਪਸਟ੍ਰੀਮ ਰੋਲ ਇਸ ਵਿਵਹਾਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ; ਉਹ java ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ। ਉਸੇ ਸਮੇਂ, ਇਹ ਸਾਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਡਿਪਲਾਇਮੈਂਟ ਤਰਕ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਇੱਕ ਜਾਵਾ ਲਾਗੂਕਰਨ/ਵਰਜਨ ਨੂੰ ਦੂਜੇ ਨਾਲ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

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

ਇੰਟਰਫੇਸ ਵੱਖ ਕਰਨ ਦਾ ਸਿਧਾਂਤ

ਇੰਟਰਫੇਸ ਵਿਭਾਜਨ ਸਿਧਾਂਤ: “ਕਈ ਕਲਾਇੰਟ-ਵਿਸ਼ੇਸ਼ ਇੰਟਰਫੇਸ ਇੱਕ ਆਮ-ਉਦੇਸ਼ ਵਾਲੇ ਇੰਟਰਫੇਸ ਨਾਲੋਂ ਬਿਹਤਰ ਹੁੰਦੇ ਹਨ।

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

ਨਿਰਭਰਤਾ ਉਲਟ ਸਿਧਾਂਤ

ਨਿਰਭਰਤਾ ਉਲਟ ਦਾ ਸਿਧਾਂਤ। ਉੱਚ ਪੱਧਰਾਂ 'ਤੇ ਮੋਡੀਊਲ ਹੇਠਲੇ ਪੱਧਰ 'ਤੇ ਮੋਡੀਊਲਾਂ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਦੋਵੇਂ ਕਿਸਮਾਂ ਦੇ ਮੋਡੀਊਲ ਐਬਸਟਰੈਕਸ਼ਨ 'ਤੇ ਨਿਰਭਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਐਬਸਟਰੈਕਸ਼ਨ ਵੇਰਵਿਆਂ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਵੇਰਵਿਆਂ ਨੂੰ ਐਬਸਟਰੈਕਸ਼ਨਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਥੇ ਉਦਾਹਰਣ ਇੱਕ ਐਂਟੀਪੈਟਰਨ 'ਤੇ ਅਧਾਰਤ ਹੋਵੇਗੀ।

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

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

ਗੱਲਬਾਤ ਕਰਨੀ

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

ਬੱਸ ਕਾਰਕ

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

ਪੇਅਰ ਡਿਵੋਪਸਿੰਗ

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

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

ਕੋਡ ਸਮੀਖਿਆ

ਵਿਸ਼ਾ-ਵਸਤੂ, ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਬਾਰੇ ਗਿਆਨ ਦਾ ਪ੍ਰਸਾਰ ਕਰਨਾ ਅਤੇ ਇਹ ਕੋਡ ਸਮੀਖਿਆ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਹ ਵਧੇਰੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸੀ:

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

ਇੱਥੇ ਮੁੱਖ ਗੱਲ ਇਹ ਸੀ ਕਿ ਸਮੀਖਿਅਕਾਂ ਨੂੰ ਇੱਕ ਇੱਕ ਅਨੁਸੂਚੀ ਦੇ ਅਨੁਸਾਰ ਚੁਣਿਆ ਗਿਆ ਸੀ, ਯਾਨੀ. ਕੁਝ ਹੱਦ ਤੱਕ ਸੰਭਾਵਨਾ ਦੇ ਨਾਲ ਤੁਸੀਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਇੱਕ ਨਵੇਂ ਹਿੱਸੇ ਵਿੱਚ ਚੜ੍ਹੋਗੇ।

ਕੋਡ ਸ਼ੈਲੀ

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

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

ਗ੍ਰੀਨ ਬਿਲਡ ਮਾਸਟਰ

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

ਇੱਕ ਵੱਖਰੀ ਸ਼ਾਖਾ ਵਿੱਚ ਵਿਕਾਸ ਚੱਲ ਰਿਹਾ ਹੈ।
ਇਸ ਥਰਿੱਡ 'ਤੇ ਟੈਸਟ ਚੱਲ ਰਹੇ ਹਨ।
ਜੇਕਰ ਟੈਸਟ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਕੋਡ ਇਸਨੂੰ ਮਾਸਟਰ ਵਿੱਚ ਨਹੀਂ ਬਣਾਏਗਾ।

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

IaC ਟੈਸਟਿੰਗ

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

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

IaC ਟੈਸਟਿੰਗ ਪਿਰਾਮਿਡ

IaC ਟੈਸਟਿੰਗ: ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ

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

ਬਾਸ਼ ਗੁੰਝਲਦਾਰ ਹੈ

ਆਉ ਇੱਕ ਮਾਮੂਲੀ ਉਦਾਹਰਣ ਵੱਲ ਧਿਆਨ ਦੇਈਏ। ਮੌਜੂਦਾ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਦੀ ਚੋਣ ਕਰੋ ਅਤੇ ਕਿਸੇ ਹੋਰ ਸਥਾਨ ਤੇ ਕਾਪੀ ਕਰੋ। ਪਹਿਲੀ ਗੱਲ ਜੋ ਮਨ ਵਿੱਚ ਆਉਂਦੀ ਹੈ:

for i in * ; do 
    cp $i /some/path/$i.bak
done

ਜੇਕਰ ਫਾਈਲ ਨਾਮ ਵਿੱਚ ਇੱਕ ਸਪੇਸ ਹੈ ਤਾਂ ਕੀ ਹੋਵੇਗਾ? ਠੀਕ ਹੈ, ਅਸੀਂ ਹੁਸ਼ਿਆਰ ਹਾਂ, ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਹਵਾਲੇ ਕਿਵੇਂ ਵਰਤਣੇ ਹਨ:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

ਬਹੁਤ ਖੂਬ? ਨਹੀਂ! ਕੀ ਜੇ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਕੁਝ ਵੀ ਨਹੀਂ ਹੈ, ਜਿਵੇਂ ਕਿ. ਗਲੋਬਿੰਗ ਕੰਮ ਨਹੀਂ ਕਰੇਗੀ।

find . -type f -exec mv -v {} dst/{}.bak ;

ਹੁਣ ਚੰਗਾ ਕੀਤਾ? ਨਹੀਂ... ਭੁੱਲ ਗਏ ਕਿ ਫਾਈਲ ਨਾਮ ਵਿੱਚ ਕੀ ਹੋ ਸਕਦਾ ਹੈ n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਟੂਲ

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

ਭਾਸ਼ਾ
ਟੂਲ

bash
ਸ਼ੈੱਲਚੈਕ

ਰੂਬੀ
RuboCop

ਪਾਇਥਨ
ਪਾਇਲਟ

ਜਵਾਬਦੇਹ
ਜਵਾਬਦੇਹ ਲਿੰਟ

IaC ਟੈਸਟਿੰਗ: ਯੂਨਿਟ ਟੈਸਟ

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

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

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

IaC ਟੈਸਟਿੰਗ: ਯੂਨਿਟ ਟੈਸਟਿੰਗ ਟੂਲ

ਸਵਾਲ, CFM ਲਈ ਟੈਸਟ ਕੀ ਹਨ? ਤੁਸੀਂ ਸਿਰਫ਼ ਸਕ੍ਰਿਪਟ ਨੂੰ ਚਲਾ ਸਕਦੇ ਹੋ, ਜਾਂ ਤੁਸੀਂ ਇਸਦੇ ਲਈ ਤਿਆਰ ਕੀਤੇ ਹੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ:

CFM
ਟੂਲ

Ansimate
ਟੈਸਟਿਨਫ੍ਰਾ

ਸਿਰ '
ਇੰਸਪੈਕਟਰ

ਸਿਰ '
ਸਰਵਰਸਪੇਕ

ਨਮਕ ਸਟੈਕ
ਗਾਸ

testinfra ਲਈ ਉਦਾਹਰਨ, ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਜਾਂਚ ਕਰਨਾ test1, test2 ਮੌਜੂਦ ਹਨ ਅਤੇ ਇੱਕ ਸਮੂਹ ਵਿੱਚ ਹਨ sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

ਕੀ ਚੁਣਨਾ ਹੈ? ਸਵਾਲ ਗੁੰਝਲਦਾਰ ਅਤੇ ਅਸਪਸ਼ਟ ਹੈ, ਇੱਥੇ 2018-2019 ਲਈ ਗਿਥਬ 'ਤੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਹੈ:

IaC ਟੈਸਟਿੰਗ ਫਰੇਮਵਰਕ

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

CFM
ਟੂਲ

Ansimate
ਅਣੂ

ਸਿਰ '
ਟੈਸਟ ਰਸੋਈ

ਟੈਰਾਫਾਰਮ
ਟੈਰੇਟੈਸਟ

2018-2019 ਲਈ github 'ਤੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦੀ ਉਦਾਹਰਨ:

ਅਣੂ ਬਨਾਮ. ਟੈਸਟ ਕਿਚਨ

ਸ਼ੁਰੂ ਵਿਚ ਅਸੀਂ ਟੈਸਟਕਿਚਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ:

ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਇੱਕ VM ਬਣਾਓ।
ਜਵਾਬਦੇਹ ਭੂਮਿਕਾਵਾਂ ਲਾਗੂ ਕਰੋ।
ਨਿਰੀਖਣ ਚਲਾਓ.

25-35 ਭੂਮਿਕਾਵਾਂ ਲਈ ਇਸ ਨੇ 40-70 ਮਿੰਟ ਕੰਮ ਕੀਤਾ, ਜੋ ਕਿ ਲੰਬਾ ਸੀ।

ਅਗਲਾ ਕਦਮ ਜੇਨਕਿੰਸ/ਡੌਕਰ/ਅਨਸੀਬਲ/ਅਣੂ ਵਿੱਚ ਤਬਦੀਲੀ ਸੀ। ਮੁਹਾਵਰੇ ਵਿਚ ਸਭ ਕੁਝ ਇੱਕੋ ਜਿਹਾ ਹੈ

ਲਿੰਟ ਪਲੇਬੁੱਕ।
ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਲਾਈਨਅੱਪ ਕਰੋ।
ਕੰਟੇਨਰ ਲਾਂਚ ਕਰੋ
ਜਵਾਬਦੇਹ ਭੂਮਿਕਾਵਾਂ ਲਾਗੂ ਕਰੋ।
testinfra ਚਲਾਓ.
ਕਮਜ਼ੋਰੀ ਦੀ ਜਾਂਚ ਕਰੋ.

40 ਭੂਮਿਕਾਵਾਂ ਲਈ ਲਿੰਟਿੰਗ ਅਤੇ ਇੱਕ ਦਰਜਨ ਲਈ ਟੈਸਟਾਂ ਵਿੱਚ ਲਗਭਗ 15 ਮਿੰਟ ਲੱਗ ਗਏ।

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

IaC ਟੈਸਟਿੰਗ: ਏਕੀਕਰਣ ਟੈਸਟ

ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਟੈਸਟਿੰਗ ਪਿਰਾਮਿਡ ਵਿੱਚ ਅਗਲਾ ਕਦਮ ਏਕੀਕਰਣ ਟੈਸਟ ਹੋਵੇਗਾ। ਉਹ ਯੂਨਿਟ ਟੈਸਟਾਂ ਦੇ ਸਮਾਨ ਹਨ:

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

ਮੋਟੇ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਸਿਸਟਮ ਦੇ ਵਿਅਕਤੀਗਤ ਤੱਤ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰਦੇ ਜਿਵੇਂ ਕਿ ਯੂਨਿਟ ਟੈਸਟਾਂ ਵਿੱਚ, ਅਸੀਂ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ਕਿ ਸਰਵਰ ਨੂੰ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਕਿਵੇਂ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ।

IaC ਟੈਸਟਿੰਗ: ਅੰਤ ਤੋਂ ਅੰਤ ਤੱਕ ਟੈਸਟ

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

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

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

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

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

ਸਿੱਟਾ

ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਜਿਵੇਂ ਕੋਡ ਹੈ

ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਕੋਡ.
ਮਨੁੱਖੀ ਪਰਸਪਰ ਪ੍ਰਭਾਵ.
ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਜਾਂਚ.

ਲਿੰਕ

ਸਰੋਤ: www.habr.com

ਮੈਂ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਕੋਡ ਦੀਆਂ 200 ਲਾਈਨਾਂ ਦੀ ਜਾਂਚ ਤੋਂ ਕੀ ਸਿੱਖਿਆ ਹੈ