ਕੋਰਸ ਦੇ ਵਿਦਿਆਰਥੀਆਂ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਲੇਖ ਦਾ ਅਨੁਵਾਦ "DevOps ਅਭਿਆਸ ਅਤੇ ਸਾਧਨ" OTUS ਵਿਦਿਅਕ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ।

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

ਅਸੀਂ ਇਸ ਬਾਰੇ ਕਿਉਂ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ?

ਮੈਟ ਕਲੇਨ ਨੇ ਲੇਖ ਲਿਖਿਆ "ਮੋਨੋਰੇਪੋਸ: ਕਿਰਪਾ ਕਰਕੇ ਨਾ ਕਰੋ!"  (ਅਨੁਵਾਦਕ ਦਾ ਨੋਟ: Habré ਉੱਤੇ ਅਨੁਵਾਦ "ਮੋਨੋਰੇਪੋਜ਼ਿਟਰੀਆਂ: ਕਿਰਪਾ ਕਰਕੇ ਨਾ ਕਰੋ"). ਮੈਨੂੰ ਮੈਟ ਪਸੰਦ ਹੈ, ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਉਹ ਬਹੁਤ ਹੁਸ਼ਿਆਰ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਉਸਦਾ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਪੜ੍ਹਨਾ ਚਾਹੀਦਾ ਹੈ। ਉਸਨੇ ਅਸਲ ਵਿੱਚ ਟਵਿੱਟਰ 'ਤੇ ਪੋਲ ਪੋਸਟ ਕੀਤਾ:

ਅਨੁਵਾਦ:
ਇਸ ਨਵੇਂ ਸਾਲ ਦੇ ਦਿਨ, ਮੈਂ ਇਸ ਬਾਰੇ ਬਹਿਸ ਕਰਨ ਜਾ ਰਿਹਾ ਹਾਂ ਕਿ ਮੋਨੋਰੋਪੋਜ਼ਿਟਰੀਆਂ ਕਿੰਨੀਆਂ ਹਾਸੋਹੀਣੇ ਹਨ। 2019 ਚੁੱਪਚਾਪ ਸ਼ੁਰੂ ਹੋਇਆ। ਇਸ ਭਾਵਨਾ ਵਿੱਚ, ਮੈਂ ਤੁਹਾਨੂੰ ਇੱਕ ਸਰਵੇਖਣ ਪੇਸ਼ ਕਰਦਾ ਹਾਂ। ਵੱਡੇ ਕੱਟੜਪੰਥੀ ਕੌਣ ਹਨ? ਸਮਰਥਕ:
- ਮੋਨੋਰੇਪੋ
- ਜੰਗਾਲ
- ਗਲਤ ਪੋਲ/ਦੋਵੇਂ

ਮੇਰਾ ਜਵਾਬ ਸੀ, "ਮੈਂ ਅਸਲ ਵਿੱਚ ਉਹ ਦੋਵੇਂ ਲੋਕ ਹਾਂ।" ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਨ ਦੀ ਬਜਾਏ ਕਿ ਜੰਗਾਲ ਇੱਕ ਡਰੱਗ ਕਿਵੇਂ ਹੈ, ਆਓ ਦੇਖੀਏ ਕਿ ਮੈਂ ਕਿਉਂ ਸੋਚਦਾ ਹਾਂ ਕਿ ਉਹ ਮੋਨੋਰੋਪੋਜ਼ਿਟਰੀਆਂ ਬਾਰੇ ਗਲਤ ਹੈ. ਆਪਣੇ ਬਾਰੇ ਥੋੜਾ ਜਿਹਾ. ਮੈਂ ਸ਼ੈੱਫ ਸੌਫਟਵੇਅਰ ਦਾ ਸੀ.ਟੀ.ਓ. ਸਾਡੇ ਕੋਲ ਲਗਭਗ 100 ਇੰਜੀਨੀਅਰ ਹਨ, ਇੱਕ ਕੋਡ ਬੇਸ ਲਗਭਗ 11-12 ਸਾਲ ਪੁਰਾਣਾ ਹੈ, ਅਤੇ 4 ਮੁੱਖ ਉਤਪਾਦ ਹਨ। ਇਸ ਕੋਡ ਵਿੱਚੋਂ ਕੁਝ ਇੱਕ ਪੌਲੀਰੀਪੋਜ਼ਟਰੀ (ਮੇਰੀ ਸ਼ੁਰੂਆਤੀ ਸਥਿਤੀ) ਵਿੱਚ ਹੈ, ਕੁਝ ਇੱਕ ਮੋਨੋਰੇਪੋਜ਼ਟਰੀ (ਮੇਰੀ ਮੌਜੂਦਾ ਸਥਿਤੀ) ਵਿੱਚ ਹੈ।

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

ਮੈਂ ਮੈਟ ਦੇ ਪੁਆਇੰਟ ਦੇ ਪਹਿਲੇ ਹਿੱਸੇ ਨਾਲ ਸਹਿਮਤ ਹਾਂ:

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

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

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

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

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

ਇਹ ਸੰਚਾਰ ਨੂੰ ਭੜਕਾਉਂਦਾ ਹੈ ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ

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

ਜਿਵੇਂ ਕਿ ਆਰਕੀਟੈਕਚਰ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਇੱਕ ਟੀਮ ਹੁਣ ਇਸ ਨੂੰ ਇਕੱਲੇ ਪ੍ਰਬੰਧਨ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਬਹੁਤ ਘੱਟ ਇੰਜੀਨੀਅਰਾਂ ਦੇ ਸਿਰ ਵਿੱਚ ਪੂਰਾ ਸਿਸਟਮ ਹੁੰਦਾ ਹੈ। ਮੰਨ ਲਓ ਕਿ ਤੁਸੀਂ ਇੱਕ ਸਾਂਝੇ ਕੰਪੋਨੈਂਟ A ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੇ ਹੋ ਜੋ ਕਿ ਟੀਮਾਂ B, C, ਅਤੇ D ਦੁਆਰਾ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਟੀਮ A ਰੀਫੈਕਟਰਿੰਗ ਕਰ ਰਹੀ ਹੈ, API ਵਿੱਚ ਸੁਧਾਰ ਕਰ ਰਹੀ ਹੈ, ਅਤੇ ਅੰਦਰੂਨੀ ਲਾਗੂਕਰਨ ਨੂੰ ਵੀ ਬਦਲ ਰਹੀ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਤਬਦੀਲੀਆਂ ਪਿੱਛੇ ਵੱਲ ਅਨੁਕੂਲ ਨਹੀਂ ਹਨ। ਤੁਹਾਨੂੰ ਕੀ ਸਲਾਹ ਹੈ?

• ਉਹ ਸਾਰੀਆਂ ਥਾਵਾਂ ਲੱਭੋ ਜਿੱਥੇ ਪੁਰਾਣੀ API ਵਰਤੀ ਜਾਂਦੀ ਹੈ।
• ਕੀ ਅਜਿਹੀਆਂ ਥਾਵਾਂ ਹਨ ਜਿੱਥੇ ਨਵੇਂ API ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ?
• ਕੀ ਤੁਸੀਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਦੂਜੇ ਭਾਗਾਂ ਨੂੰ ਠੀਕ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਉਹ ਟੁੱਟਣ ਨਹੀਂ ਹਨ?
• ਕੀ ਇਹ ਟੀਮਾਂ ਹੁਣੇ ਤੁਹਾਡੀਆਂ ਤਬਦੀਲੀਆਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੀਆਂ ਹਨ?

ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਕਿ ਇਹ ਸਵਾਲ ਰਿਪੋਜ਼ਟਰੀ ਕਿਸਮ ਤੋਂ ਸੁਤੰਤਰ ਹਨ। ਤੁਹਾਨੂੰ B, C ਅਤੇ D ਟੀਮਾਂ ਲੱਭਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਨਾਲ ਗੱਲ ਕਰਨ, ਸਮਾਂ ਪਤਾ ਕਰਨ, ਉਹਨਾਂ ਦੀਆਂ ਤਰਜੀਹਾਂ ਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਘੱਟੋ-ਘੱਟ ਸਾਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਤੁਸੀਂ ਕਰੋਗੇ।

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

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

ਫਿਰ ਸਾਨੂੰ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਨੀ ਪਵੇਗੀ ਕਿ ਅਸੀਂ ਇਸ ਸਥਿਤੀ ਤੋਂ ਕਿਵੇਂ ਨਿਕਲਾਂਗੇ:

1. ਮਲਟੀਪਲ ਅੰਦਰੂਨੀ API ਲਈ ਸਮਰਥਨ, ਅਤੇ ਪੁਰਾਣੇ ਐਲਗੋਰਿਦਮ ਨੂੰ ਬਰਤਰਫ਼ ਕੀਤੇ ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕਰੇਗਾ ਜਦੋਂ ਤੱਕ D ਇਸਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬੰਦ ਨਹੀਂ ਕਰ ਦਿੰਦਾ।
2. ਮਲਟੀਪਲ ਰੀਲੀਜ਼ ਸੰਸਕਰਣਾਂ ਲਈ ਸਮਰਥਨ, ਇੱਕ ਪੁਰਾਣੇ ਇੰਟਰਫੇਸ ਨਾਲ, ਇੱਕ ਨਵੇਂ ਨਾਲ।
3. A ਦੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਜਾਰੀ ਕਰਨ ਵਿੱਚ ਦੇਰੀ ਉਦੋਂ ਤੱਕ ਕਰੋ ਜਦੋਂ ਤੱਕ B, C, ਅਤੇ D ਇਸ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰ ਲੈਂਦੇ।

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

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

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

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

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

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

ਸਿਰਫ਼ ਰਜਿਸਟਰਡ ਉਪਭੋਗਤਾ ਹੀ ਸਰਵੇਖਣ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਹਨ। ਸਾਈਨ - ਇਨ, ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ.

ਸਭ ਤੋਂ ਵੱਡੇ ਕੱਟੜਪੰਥੀ ਕੌਣ ਹਨ? ਸਮਰਥਕ:

• ਮੋਨੋਰੇਪੋ

• ਜੰਗਾਲ

• ਗਲਤ ਪੋਲ/ਦੋਵੇਂ

33 ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਵੋਟ ਕੀਤਾ। 13 ਉਪਭੋਗਤਾ ਬਚੇ ਰਹੇ।

ਸਰੋਤ: www.habr.com