ਅਸੀਂ DevOps ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਢੰਗ ਨਾਲ ਵਿਕਸਿਤ ਕੀਤਾ ਹੈ। ਸਾਡੇ ਵਿੱਚੋਂ 8 ਸਨ, ਅਤੇ ਵਾਸਿਆ ਵਿੰਡੋਜ਼ ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੀਆ ਸੀ। ਅਚਾਨਕ ਵਾਸਿਆ ਚਲਾ ਗਿਆ, ਅਤੇ ਮੇਰੇ ਕੋਲ ਇੱਕ ਨਵਾਂ ਪ੍ਰੋਜੈਕਟ ਲਾਂਚ ਕਰਨ ਦਾ ਕੰਮ ਸੀ ਜੋ ਵਿੰਡੋਜ਼ ਡਿਵੈਲਪਮੈਂਟ ਦੁਆਰਾ ਸਪਲਾਈ ਕੀਤਾ ਗਿਆ ਸੀ. ਜਦੋਂ ਮੈਂ ਸਾਰਾ ਵਿੰਡੋਜ਼ ਡਿਵੈਲਪਮੈਂਟ ਸਟੈਕ ਟੇਬਲ 'ਤੇ ਸੁੱਟ ਦਿੱਤਾ, ਮੈਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਸਥਿਤੀ ਇੱਕ ਦਰਦ ਸੀ...
ਇਸ ਤਰ੍ਹਾਂ ਕਹਾਣੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਅਲੈਗਜ਼ੈਂਡਰਾ ਸਿੰਚਿਨੋਵਾ 'ਤੇ . ਜਦੋਂ ਪ੍ਰਮੁੱਖ ਵਿੰਡੋਜ਼ ਮਾਹਰ ਨੇ ਕੰਪਨੀ ਛੱਡ ਦਿੱਤੀ, ਤਾਂ ਅਲੈਗਜ਼ੈਂਡਰ ਨੇ ਸੋਚਿਆ ਕਿ ਹੁਣ ਕੀ ਕਰਨਾ ਹੈ। ਲੀਨਕਸ 'ਤੇ ਸਵਿਚ ਕਰੋ, ਬੇਸ਼ਕ! ਅਲੈਗਜ਼ੈਂਡਰ ਤੁਹਾਨੂੰ ਦੱਸੇਗਾ ਕਿ ਉਸਨੇ 100 ਅੰਤਮ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਇੱਕ ਮੁਕੰਮਲ ਪ੍ਰੋਜੈਕਟ ਦੀ ਉਦਾਹਰਣ ਦੀ ਵਰਤੋਂ ਕਰਦਿਆਂ ਵਿੰਡੋਜ਼ ਡਿਵੈਲਪਮੈਂਟ ਦੇ ਇੱਕ ਹਿੱਸੇ ਨੂੰ ਲੀਨਕਸ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਵਿੱਚ ਕਿਵੇਂ ਪ੍ਰਬੰਧਿਤ ਕੀਤਾ।
TFS, Puppet, Linux .NET ਕੋਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਆਸਾਨੀ ਨਾਲ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਨੂੰ RPM ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਾਉਣਾ ਹੈ? ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਡੇਟਾਬੇਸ ਦੇ ਸੰਸਕਰਣ ਦਾ ਸਮਰਥਨ ਕਿਵੇਂ ਕਰਨਾ ਹੈ ਜੇਕਰ ਵਿਕਾਸ ਟੀਮ ਪਹਿਲੀ ਵਾਰ ਪੋਸਟਗ੍ਰੇਸ ਅਤੇ ਫਲਾਈਵੇ ਸ਼ਬਦ ਸੁਣਦੀ ਹੈ, ਅਤੇ ਆਖਰੀ ਮਿਤੀ ਕੱਲ੍ਹ ਤੋਂ ਬਾਅਦ ਹੈ? ਡੌਕਰ ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਕਿਵੇਂ ਕਰੀਏ? .NET ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਕਠਪੁਤਲੀ ਅਤੇ ਲੀਨਕਸ ਦੇ ਪੱਖ ਵਿੱਚ ਵਿੰਡੋਜ਼ ਅਤੇ ਸਮੂਦੀਜ਼ ਨੂੰ ਛੱਡਣ ਲਈ ਕਿਵੇਂ ਪ੍ਰੇਰਿਤ ਕਰਨਾ ਹੈ? ਵਿਚਾਰਧਾਰਕ ਟਕਰਾਅ ਨੂੰ ਕਿਵੇਂ ਸੁਲਝਾਉਣਾ ਹੈ ਜੇਕਰ ਉਤਪਾਦਨ ਵਿੱਚ ਵਿੰਡੋਜ਼ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਲਈ ਨਾ ਤਾਂ ਤਾਕਤ, ਨਾ ਇੱਛਾ, ਅਤੇ ਨਾ ਹੀ ਸਰੋਤ ਹਨ? ਇਸ ਬਾਰੇ, ਨਾਲ ਹੀ ਅਲੈਗਜ਼ੈਂਡਰ ਦੀ ਰਿਪੋਰਟ ਦੀ ਪ੍ਰਤੀਲਿਪੀ ਵਿੱਚ, ਵੈੱਬ ਡਿਪਲੋਏ, ਟੈਸਟਿੰਗ, ਸੀਆਈ ਬਾਰੇ, ਮੌਜੂਦਾ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਟੀਐਫਐਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਅਭਿਆਸਾਂ ਬਾਰੇ, ਅਤੇ, ਬੇਸ਼ੱਕ, ਟੁੱਟੀਆਂ ਬੈਸਾਖੀਆਂ ਅਤੇ ਕਾਰਜਸ਼ੀਲ ਹੱਲਾਂ ਬਾਰੇ।
ਇਸ ਲਈ, ਵਸਿਆ ਛੱਡ ਦਿੱਤਾ, ਕੰਮ ਮੇਰੇ 'ਤੇ ਹੈ, ਡਿਵੈਲਪਰ ਪਿੱਚਫੋਰਕਸ ਨਾਲ ਬੇਸਬਰੀ ਨਾਲ ਉਡੀਕ ਕਰ ਰਹੇ ਹਨ. ਜਦੋਂ ਮੈਨੂੰ ਆਖ਼ਰਕਾਰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਵਾਸਿਆ ਵਾਪਸ ਨਹੀਂ ਆ ਸਕਦਾ, ਤਾਂ ਮੈਂ ਕਾਰੋਬਾਰ 'ਤੇ ਉਤਰ ਗਿਆ। ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਮੈਂ ਸਾਡੇ ਫਲੀਟ ਵਿੱਚ Win VMs ਦੀ ਪ੍ਰਤੀਸ਼ਤਤਾ ਦਾ ਮੁਲਾਂਕਣ ਕੀਤਾ। ਸਕੋਰ ਵਿੰਡੋਜ਼ ਦੇ ਹੱਕ ਵਿੱਚ ਨਹੀਂ ਸੀ।
ਕਿਉਂਕਿ ਅਸੀਂ ਸਰਗਰਮੀ ਨਾਲ DevOps ਦਾ ਵਿਕਾਸ ਕਰ ਰਹੇ ਹਾਂ, ਮੈਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਇੱਕ ਨਵੀਂ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਪਹੁੰਚ ਵਿੱਚ ਕੁਝ ਬਦਲਣ ਦੀ ਲੋੜ ਹੈ। ਸਿਰਫ ਇੱਕ ਹੱਲ ਸੀ - ਜੇ ਸੰਭਵ ਹੋਵੇ, ਤਾਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਲੀਨਕਸ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰੋ. ਗੂਗਲ ਨੇ ਮੇਰੀ ਮਦਦ ਕੀਤੀ - ਉਸ ਸਮੇਂ .Net ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਲੀਨਕਸ ਵਿੱਚ ਪੋਰਟ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਮੈਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਇਹ ਹੱਲ ਸੀ!
ਲੀਨਕਸ ਦੇ ਨਾਲ .NET ਕੋਰ ਕਿਉਂ?
ਇਸ ਦੇ ਕਈ ਕਾਰਨ ਸਨ। "ਪੈਸੇ ਦਾ ਭੁਗਤਾਨ ਕਰੋ" ਅਤੇ "ਭੁਗਤਾਨ ਨਾ ਕਰੋ" ਦੇ ਵਿਚਕਾਰ, ਬਹੁਮਤ ਦੂਜੇ ਨੂੰ ਚੁਣੇਗਾ - ਮੇਰੇ ਵਾਂਗ। MSDB ਲਈ ਇੱਕ ਲਾਇਸੰਸ ਦੀ ਕੀਮਤ ਲਗਭਗ $1 ਹੈ; ਵਿੰਡੋਜ਼ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਦੇ ਫਲੀਟ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਲਈ ਸੈਂਕੜੇ ਡਾਲਰ ਖਰਚ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਵੱਡੀ ਕੰਪਨੀ ਲਈ ਇਹ ਇੱਕ ਵੱਡਾ ਖਰਚ ਹੈ. ਇਸ ਕਰਕੇ ਬਚਤ - ਪਹਿਲਾ ਕਾਰਨ. ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ, ਪਰ ਮਹੱਤਵਪੂਰਨ ਵਿੱਚੋਂ ਇੱਕ.
ਵਿੰਡੋਜ਼ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਆਪਣੇ ਲੀਨਕਸ ਭਰਾਵਾਂ ਨਾਲੋਂ ਵਧੇਰੇ ਸਰੋਤ ਲੈਂਦੀਆਂ ਹਨ - ਉਹ ਭਾਰੀ ਹਨ. ਵੱਡੀ ਕੰਪਨੀ ਦੇ ਪੈਮਾਨੇ ਦੇ ਮੱਦੇਨਜ਼ਰ, ਅਸੀਂ ਲੀਨਕਸ ਨੂੰ ਚੁਣਿਆ।
ਸਿਸਟਮ ਨੂੰ ਸਿਰਫ਼ ਮੌਜੂਦਾ CI ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਹੈ. ਅਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਪ੍ਰਗਤੀਸ਼ੀਲ DevOps ਸਮਝਦੇ ਹਾਂ, ਅਸੀਂ Bamboo, Jenkins ਅਤੇ GitLab CI ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਇਸਲਈ ਸਾਡਾ ਜ਼ਿਆਦਾਤਰ ਕੰਮ ਲੀਨਕਸ 'ਤੇ ਚੱਲਦਾ ਹੈ।
ਆਖਰੀ ਕਾਰਨ ਹੈ ਸੁਵਿਧਾਜਨਕ ਸੰਗਤ. ਸਾਨੂੰ "ਏਸਕੌਰਟਸ" ਲਈ ਦਾਖਲੇ ਦੀ ਰੁਕਾਵਟ ਨੂੰ ਘੱਟ ਕਰਨ ਦੀ ਲੋੜ ਸੀ—ਉਹ ਲੋਕ ਜੋ ਤਕਨੀਕੀ ਹਿੱਸੇ ਨੂੰ ਸਮਝਦੇ ਹਨ, ਨਿਰਵਿਘਨ ਸੇਵਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਦੂਜੀ ਲਾਈਨ ਤੋਂ ਸੇਵਾਵਾਂ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹਨ। ਉਹ ਪਹਿਲਾਂ ਹੀ ਲੀਨਕਸ ਸਟੈਕ ਤੋਂ ਜਾਣੂ ਸਨ, ਇਸਲਈ ਉਹਨਾਂ ਲਈ ਵਿੰਡੋਜ਼ ਪਲੇਟਫਾਰਮ ਲਈ ਸੌਫਟਵੇਅਰ ਦੀ ਸਮਾਨ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਸਮਝਣ ਲਈ ਵਾਧੂ ਸਰੋਤ ਖਰਚਣ ਨਾਲੋਂ ਇੱਕ ਨਵੇਂ ਉਤਪਾਦ ਨੂੰ ਸਮਝਣਾ, ਸਮਰਥਨ ਕਰਨਾ ਅਤੇ ਇਸਨੂੰ ਕਾਇਮ ਰੱਖਣਾ ਬਹੁਤ ਸੌਖਾ ਹੈ।
ਲੋੜ
ਪਹਿਲਾ ਤੇ ਸਿਰਮੌਰ - ਡਿਵੈਲਪਰਾਂ ਲਈ ਨਵੇਂ ਹੱਲ ਦੀ ਸਹੂਲਤ. ਉਹ ਸਾਰੇ ਬਦਲਾਅ ਲਈ ਤਿਆਰ ਨਹੀਂ ਸਨ, ਖਾਸ ਤੌਰ 'ਤੇ ਲੀਨਕਸ ਸ਼ਬਦ ਬੋਲੇ ਜਾਣ ਤੋਂ ਬਾਅਦ। ਡਿਵੈਲਪਰ ਅਸੈਂਬਲੀਆਂ ਅਤੇ ਸਮੂਦੀਜ਼ ਲਈ ਆਟੋਟੈਸਟਾਂ ਦੇ ਨਾਲ ਆਪਣਾ ਮਨਪਸੰਦ ਵਿਜ਼ੂਅਲ ਸਟੂਡੀਓ, TFS ਚਾਹੁੰਦੇ ਹਨ। ਉਤਪਾਦਨ ਲਈ ਡਿਲੀਵਰੀ ਕਿਵੇਂ ਹੁੰਦੀ ਹੈ ਇਹ ਉਨ੍ਹਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ। ਇਸ ਲਈ, ਅਸੀਂ ਆਮ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਨਾ ਬਦਲਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਅਤੇ ਵਿੰਡੋਜ਼ ਦੇ ਵਿਕਾਸ ਲਈ ਹਰ ਚੀਜ਼ ਨੂੰ ਬਦਲਿਆ ਨਹੀਂ ਛੱਡਿਆ ਹੈ।
ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ਦੀ ਲੋੜ ਹੈ ਮੌਜੂਦਾ CI ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ. ਰੇਲਾਂ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਸਨ ਅਤੇ ਸਾਰਾ ਕੰਮ ਸੰਰਚਨਾ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀ ਦੇ ਮਾਪਦੰਡਾਂ, ਪ੍ਰਵਾਨਿਤ ਡਿਲੀਵਰੀ ਮਾਪਦੰਡਾਂ ਅਤੇ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਕੀਤਾ ਜਾਣਾ ਸੀ।
ਸਹਾਇਤਾ ਅਤੇ ਕਾਰਵਾਈ ਦੀ ਸੌਖ, ਵੱਖ-ਵੱਖ ਡਿਵੀਜ਼ਨਾਂ ਅਤੇ ਸਹਾਇਤਾ ਵਿਭਾਗ ਦੇ ਸਾਰੇ ਨਵੇਂ ਭਾਗੀਦਾਰਾਂ ਲਈ ਘੱਟੋ-ਘੱਟ ਐਂਟਰੀ ਥ੍ਰੈਸ਼ਹੋਲਡ ਦੀ ਸ਼ਰਤ ਵਜੋਂ।
ਅੰਤਮ ਤਾਰੀਖ - ਕੱਲ੍ਹ.
ਵਿਨ ਡਿਵੈਲਪਮੈਂਟ ਗਰੁੱਪ
ਵਿੰਡੋਜ਼ ਟੀਮ ਉਸ ਸਮੇਂ ਕਿਸ ਨਾਲ ਕੰਮ ਕਰ ਰਹੀ ਸੀ?
ਹੁਣ ਮੈਂ ਭਰੋਸੇ ਨਾਲ ਕਹਿ ਸਕਦਾ ਹਾਂ ਪਛਾਣ ਸਰਵਰ 4 ਸਮਾਨ ਸਮਰੱਥਾਵਾਂ ਵਾਲੇ ADFS ਦਾ ਇੱਕ ਠੰਡਾ ਮੁਫਤ ਵਿਕਲਪ ਹੈ, ਜਾਂ ਕੀ ਇਕਾਈ ਫਰੇਮਵਰਕ ਕੋਰ - ਇੱਕ ਡਿਵੈਲਪਰ ਲਈ ਇੱਕ ਫਿਰਦੌਸ, ਜਿੱਥੇ ਤੁਹਾਨੂੰ SQL ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਲਿਖਣ ਦੀ ਪਰੇਸ਼ਾਨੀ ਨਹੀਂ ਕਰਨੀ ਪੈਂਦੀ, ਪਰ OOP ਸ਼ਬਦਾਂ ਵਿੱਚ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਵਾਲਾਂ ਦਾ ਵਰਣਨ ਕਰੋ। ਪਰ ਫਿਰ, ਐਕਸ਼ਨ ਪਲਾਨ ਦੀ ਚਰਚਾ ਦੇ ਦੌਰਾਨ, ਮੈਂ ਇਸ ਸਟੈਕ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦੇਖਿਆ ਜਿਵੇਂ ਕਿ ਇਹ ਸੁਮੇਰੀਅਨ ਕਿਊਨੀਫਾਰਮ ਸੀ, ਸਿਰਫ PostgreSQL ਅਤੇ Git ਨੂੰ ਪਛਾਣਦਾ ਹੈ.
ਉਸ ਸਮੇਂ ਅਸੀਂ ਸਰਗਰਮੀ ਨਾਲ ਵਰਤ ਰਹੇ ਸੀ ਕਠਪੁਤਲੀ ਇੱਕ ਸੰਰਚਨਾ ਪ੍ਰਬੰਧਨ ਸਿਸਟਮ ਦੇ ਰੂਪ ਵਿੱਚ. ਸਾਡੇ ਬਹੁਤੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਅਸੀਂ ਵਰਤਿਆ ਗਿੱਟਲਾਬ ਸੀ.ਆਈ., ਲਚਕੀਲੇ, ਸੰਤੁਲਿਤ ਉੱਚ-ਲੋਡ ਸੇਵਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ HAProxy ਨਾਲ ਹਰ ਚੀਜ਼ ਦੀ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜ਼ੱਬਿਕਸ, ਲਿਗਾਮੈਂਟਸ ਗ੍ਰਾਫਨਾ и Prometheus, ਜਗੇਰ, ਅਤੇ ਇਹ ਸਭ ਲੋਹੇ ਦੇ ਟੁਕੜਿਆਂ 'ਤੇ ਘੁੰਮ ਰਿਹਾ ਸੀ HP c ESXi 'ਤੇ VMware. ਹਰ ਕੋਈ ਇਸ ਨੂੰ ਜਾਣਦਾ ਹੈ - ਸ਼ੈਲੀ ਦਾ ਇੱਕ ਕਲਾਸਿਕ.
ਆਉ ਦੇਖੀਏ ਅਤੇ ਇਹ ਸਮਝਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ ਕਿ ਇਹ ਸਾਰੇ ਦਖਲ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਹੋਇਆ ਸੀ।
ਕੀ ਹੋਇਆ
TFS ਇੱਕ ਕਾਫ਼ੀ ਸ਼ਕਤੀਸ਼ਾਲੀ ਪ੍ਰਣਾਲੀ ਹੈ ਜੋ ਨਾ ਸਿਰਫ਼ ਡਿਵੈਲਪਰ ਤੋਂ ਅੰਤਮ ਉਤਪਾਦਨ ਮਸ਼ੀਨ ਤੱਕ ਕੋਡ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ, ਸਗੋਂ ਵੱਖ-ਵੱਖ ਸੇਵਾਵਾਂ ਦੇ ਨਾਲ ਬਹੁਤ ਲਚਕਦਾਰ ਏਕੀਕਰਣ ਲਈ ਇੱਕ ਸੈੱਟ ਵੀ ਹੈ - ਇੱਕ ਕਰਾਸ-ਪਲੇਟਫਾਰਮ ਪੱਧਰ 'ਤੇ CI ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ।
ਪਹਿਲਾਂ, ਇਹ ਠੋਸ ਵਿੰਡੋਜ਼ ਸਨ। TFS ਨੇ ਕਈ ਬਿਲਡ ਏਜੰਟਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਜੋ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਅਸੈਂਬਲ ਕਰਨ ਲਈ ਵਰਤੇ ਗਏ ਸਨ। ਹਰੇਕ ਏਜੰਟ ਕੋਲ 3-4 ਕਰਮਚਾਰੀ ਹੁੰਦੇ ਹਨ ਤਾਂ ਜੋ ਕੰਮ ਨੂੰ ਸਮਾਨਤਾਵਾਂ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਇਆ ਜਾ ਸਕੇ। ਫਿਰ, ਰੀਲੀਜ਼ ਯੋਜਨਾਵਾਂ ਦੇ ਅਨੁਸਾਰ, TFS ਨੇ ਵਿੰਡੋਜ਼ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਨੂੰ ਤਾਜ਼ੇ ਪਕਾਏ ਹੋਏ ਬਿਲਡ ਨੂੰ ਪ੍ਰਦਾਨ ਕੀਤਾ।
ਅਸੀਂ ਕੀ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ?
ਅਸੀਂ ਡਿਲੀਵਰੀ ਅਤੇ ਵਿਕਾਸ ਲਈ TFS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇੱਕ Linux ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ 'ਤੇ ਚਲਾਉਂਦੇ ਹਾਂ, ਅਤੇ ਉਹਨਾਂ ਵਿਚਕਾਰ ਕੁਝ ਕਿਸਮ ਦਾ ਜਾਦੂ ਹੈ। ਇਹ ਮੈਜਿਕ ਬਾਕਸ ਅਤੇ ਅੱਗੇ ਕੰਮ ਦਾ ਲੂਣ ਹੈ. ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਮੈਂ ਇਸਨੂੰ ਵੱਖ ਕਰਾਂ, ਮੈਂ ਇੱਕ ਕਦਮ ਇੱਕ ਪਾਸੇ ਰੱਖਾਂਗਾ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ ਕਹਾਂਗਾ।
ਪ੍ਰੋਜੈਕਟ
ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੀਪੇਡ ਕਾਰਡਾਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਕਾਰਜਸ਼ੀਲਤਾ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ।
ਕਲਾਇੰਟ
ਦੋ ਤਰ੍ਹਾਂ ਦੇ ਯੂਜ਼ਰ ਸਨ। ਪਹਿਲਾ ਇੱਕ SSL SHA-2 ਸਰਟੀਫਿਕੇਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲੌਗਇਨ ਕਰਕੇ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕੀਤੀ। ਯੂ ਦੂਜਾ ਇੱਕ ਲੌਗਇਨ ਅਤੇ ਪਾਸਵਰਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪਹੁੰਚ ਸੀ।
ਹੈਪ੍ਰੌਕਸੀ
ਫਿਰ ਕਲਾਇੰਟ ਦੀ ਬੇਨਤੀ HAProxy ਕੋਲ ਗਈ, ਜਿਸ ਨੇ ਹੇਠ ਲਿਖੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਹੱਲ ਕੀਤਾ:
- ਪ੍ਰਾਇਮਰੀ ਅਧਿਕਾਰ;
- SSL ਸਮਾਪਤੀ;
- ਟਿਊਨਿੰਗ HTTP ਬੇਨਤੀਆਂ;
- ਪ੍ਰਸਾਰਣ ਬੇਨਤੀਆਂ।
ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਚੇਨ ਦੇ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਅਸੀਂ - ਦਾ ਅਧਿਕਾਰ ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਬਰਦਾਸ਼ਤ ਕਰ ਸਕਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਅਸੀਂ ਖੁਦ ਸੇਵਾ ਗਾਹਕਾਂ ਨੂੰ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰਦੇ ਹਾਂ।
ਤੀਜੇ ਨੁਕਤੇ ਵੱਲ ਧਿਆਨ ਦਿਓ, ਅਸੀਂ ਥੋੜ੍ਹੀ ਦੇਰ ਬਾਅਦ ਇਸ ਵੱਲ ਵਾਪਸ ਆਵਾਂਗੇ.
ਪਿੱਠਵਰਤੀ
ਉਹਨਾਂ ਨੇ ਲੀਨਕਸ ਉੱਤੇ ਬੈਕਐਂਡ ਬਣਾਉਣ ਦੀ ਯੋਜਨਾ ਬਣਾਈ। ਬੈਕਐਂਡ ਡੇਟਾਬੇਸ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦਾ ਹੈ, ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰਾਂ ਦੀ ਜ਼ਰੂਰੀ ਸੂਚੀ ਨੂੰ ਲੋਡ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ, ਅਧਿਕਾਰਤ ਉਪਭੋਗਤਾ ਕੋਲ ਕਿਹੜੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਹਨ, ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਵਿੱਤੀ ਦਸਤਾਵੇਜ਼ਾਂ 'ਤੇ ਦਸਤਖਤ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਭੇਜਣ ਲਈ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜਾਂ ਕਿਸੇ ਕਿਸਮ ਦੀ ਰਿਪੋਰਟ ਤਿਆਰ ਕਰਦਾ ਹੈ।
HAProxy ਨਾਲ ਬਚਤ
ਹਰੇਕ ਕਲਾਇੰਟ ਨੇ ਨੈਵੀਗੇਟ ਕੀਤੇ ਦੋ ਸੰਦਰਭਾਂ ਤੋਂ ਇਲਾਵਾ, ਇੱਕ ਪਛਾਣ ਸੰਦਰਭ ਵੀ ਸੀ। ਪਛਾਣ ਸਰਵਰ 4 ਬਸ ਤੁਹਾਨੂੰ ਲੌਗ ਇਨ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਇਹ ਇਸ ਲਈ ਇੱਕ ਮੁਫਤ ਅਤੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਐਨਾਲਾਗ ਹੈ ADFS - ਐਕਟਿਵ ਡਾਇਰੈਕਟਰੀ ਫੈਡਰੇਸ਼ਨ ਸੇਵਾਵਾਂ.
ਪਛਾਣ ਦੀ ਬੇਨਤੀ 'ਤੇ ਕਈ ਪੜਾਵਾਂ ਵਿੱਚ ਕਾਰਵਾਈ ਕੀਤੀ ਗਈ ਸੀ। ਪਹਿਲਾ ਕਦਮ - ਗਾਹਕ ਬੈਕਐਂਡ ਵਿੱਚ ਆ ਗਿਆ, ਜਿਸ ਨੇ ਇਸ ਸਰਵਰ ਨਾਲ ਸੰਚਾਰ ਕੀਤਾ ਅਤੇ ਕਲਾਇੰਟ ਲਈ ਟੋਕਨ ਦੀ ਮੌਜੂਦਗੀ ਦੀ ਜਾਂਚ ਕੀਤੀ। ਜੇਕਰ ਇਹ ਨਹੀਂ ਮਿਲਿਆ, ਤਾਂ ਬੇਨਤੀ ਨੂੰ ਉਸ ਸੰਦਰਭ ਵਿੱਚ ਵਾਪਸ ਕਰ ਦਿੱਤਾ ਗਿਆ ਜਿਸ ਤੋਂ ਇਹ ਆਇਆ ਸੀ, ਪਰ ਇੱਕ ਰੀਡਾਇਰੈਕਟ ਨਾਲ, ਅਤੇ ਰੀਡਾਇਰੈਕਟ ਦੇ ਨਾਲ ਇਹ ਪਛਾਣ 'ਤੇ ਚਲਾ ਗਿਆ।
ਦੂਜਾ ਕਦਮ - ਬੇਨਤੀ ਪ੍ਰਾਪਤ ਕੀਤੀ ਗਈ ਸੀ IdentityServer ਵਿੱਚ ਪ੍ਰਮਾਣਿਕਤਾ ਪੰਨੇ 'ਤੇ, ਜਿੱਥੇ ਗਾਹਕ ਰਜਿਸਟਰ ਹੋਇਆ ਹੈ, ਅਤੇ ਉਹ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਉਡੀਕਿਆ ਜਾ ਰਿਹਾ ਟੋਕਨ IdentityServer ਡੇਟਾਬੇਸ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਇਆ ਹੈ।
ਤੀਜਾ ਕਦਮ - ਕਲਾਇੰਟ ਨੂੰ ਵਾਪਸ ਭੇਜਿਆ ਗਿਆ ਸੀ ਜਿਸ ਪ੍ਰਸੰਗ ਤੋਂ ਇਹ ਆਇਆ ਹੈ।
IdentityServer4 ਦੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ: ਇਹ HTTP ਰਾਹੀਂ ਵਾਪਸੀ ਦੀ ਬੇਨਤੀ ਦਾ ਜਵਾਬ ਵਾਪਸ ਕਰਦਾ ਹੈ. ਇਸ ਗੱਲ ਦਾ ਕੋਈ ਫਰਕ ਨਹੀਂ ਪੈਂਦਾ ਕਿ ਅਸੀਂ ਸਰਵਰ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਲਈ ਕਿੰਨਾ ਵੀ ਸੰਘਰਸ਼ ਕੀਤਾ ਹੈ, ਭਾਵੇਂ ਅਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਦਸਤਾਵੇਜ਼ਾਂ ਨਾਲ ਕਿੰਨਾ ਵੀ ਸਮਝਾਇਆ ਹੈ, ਹਰ ਵਾਰ ਜਦੋਂ ਸਾਨੂੰ HTTPS ਦੁਆਰਾ ਆਏ URL ਦੇ ਨਾਲ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਕਲਾਇੰਟ ਬੇਨਤੀ ਪ੍ਰਾਪਤ ਹੋਈ, ਅਤੇ IdentityServer ਨੇ ਉਸੇ ਪ੍ਰਸੰਗ ਨੂੰ ਵਾਪਸ ਕੀਤਾ, ਪਰ HTTP ਦੇ ਨਾਲ। ਅਸੀਂ ਹੈਰਾਨ ਰਹਿ ਗਏ! ਅਤੇ ਅਸੀਂ ਇਹ ਸਭ ਪਛਾਣ ਸੰਦਰਭ ਦੁਆਰਾ HAProxy ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਹੈ, ਅਤੇ ਸਿਰਲੇਖਾਂ ਵਿੱਚ ਸਾਨੂੰ HTTP ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ HTTPS ਵਿੱਚ ਸੋਧਣਾ ਪਿਆ ਹੈ।
ਸੁਧਾਰ ਕੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਕਿੱਥੇ ਬਚਾਇਆ ਹੈ?
ਅਸੀਂ ਉਪਭੋਗਤਾਵਾਂ, ਸਰੋਤਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਨੂੰ ਅਧਿਕਾਰਤ ਕਰਨ ਲਈ ਇੱਕ ਮੁਫਤ ਹੱਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪੈਸੇ ਦੀ ਬਚਤ ਕੀਤੀ, ਕਿਉਂਕਿ ਅਸੀਂ ਇੱਕ ਵੱਖਰੇ ਹਿੱਸੇ ਵਿੱਚ IdentityServer4 ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਨੋਡ ਵਜੋਂ ਨਹੀਂ ਰੱਖਿਆ, ਪਰ ਇਸਨੂੰ ਉਸੇ ਸਰਵਰ 'ਤੇ ਬੈਕਐਂਡ ਦੇ ਨਾਲ ਵਰਤਿਆ ਹੈ ਜਿੱਥੇ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਬੈਕਐਂਡ ਚੱਲਦਾ ਹੈ। .
ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ
ਇਸ ਲਈ, ਜਿਵੇਂ ਮੈਂ ਵਾਅਦਾ ਕੀਤਾ ਸੀ - ਮੈਜਿਕ ਬਾਕਸ. ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਸਮਝਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਲੀਨਕਸ ਵੱਲ ਵਧਣ ਦੀ ਗਾਰੰਟੀ ਦਿੰਦੇ ਹਾਂ। ਆਉ ਖਾਸ ਕਾਰਜ ਤਿਆਰ ਕਰੀਏ ਜਿਹਨਾਂ ਲਈ ਹੱਲ ਦੀ ਲੋੜ ਹੈ।
ਕਠਪੁਤਲੀ ਪ੍ਰਗਟ ਹੁੰਦੀ ਹੈ। ਸੇਵਾ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਕੌਂਫਿਗਰੇਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਨ ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਲਈ, ਸ਼ਾਨਦਾਰ ਪਕਵਾਨਾਂ ਨੂੰ ਲਿਖਣਾ ਪੈਂਦਾ ਸੀ। ਪੈਨਸਿਲ ਦਾ ਇੱਕ ਰੋਲ ਸਪਸ਼ਟਤਾ ਨਾਲ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਇਹ ਕਿੰਨੀ ਜਲਦੀ ਅਤੇ ਕੁਸ਼ਲਤਾ ਨਾਲ ਕੀਤਾ ਗਿਆ ਸੀ।
ਡਿਲੀਵਰੀ ਵਿਧੀ. ਮਿਆਰੀ RPM ਹੈ। ਹਰ ਕੋਈ ਸਮਝਦਾ ਹੈ ਕਿ ਲੀਨਕਸ ਵਿੱਚ ਤੁਸੀਂ ਇਸ ਤੋਂ ਬਿਨਾਂ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਪਰ ਪ੍ਰੋਜੈਕਟ ਆਪਣੇ ਆਪ, ਅਸੈਂਬਲੀ ਤੋਂ ਬਾਅਦ, ਐਗਜ਼ੀਕਿਊਟੇਬਲ DLL ਫਾਈਲਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਸੀ. ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਲਗਭਗ 150 ਸਨ, ਪ੍ਰੋਜੈਕਟ ਕਾਫ਼ੀ ਮੁਸ਼ਕਲ ਸੀ। ਇਸ ਬਾਈਨਰੀ ਨੂੰ RPM ਵਿੱਚ ਪੈਕੇਜ ਕਰਨਾ ਅਤੇ ਇਸ ਤੋਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਤੈਨਾਤ ਕਰਨਾ ਇਕੋ ਇਕਸਾਰ ਹੱਲ ਹੈ।
ਸੰਸਕਰਣ. ਸਾਨੂੰ ਬਹੁਤ ਵਾਰ ਜਾਰੀ ਕਰਨਾ ਪੈਂਦਾ ਸੀ, ਅਤੇ ਸਾਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਪੈਂਦਾ ਸੀ ਕਿ ਪੈਕੇਜ ਦਾ ਨਾਮ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ। ਇਹ TFS ਨਾਲ ਏਕੀਕਰਣ ਦੇ ਪੱਧਰ ਦਾ ਸਵਾਲ ਹੈ। ਸਾਡੇ ਕੋਲ ਲੀਨਕਸ 'ਤੇ ਇੱਕ ਬਿਲਡ ਏਜੰਟ ਸੀ। ਜਦੋਂ TFS ਇੱਕ ਕੰਮ ਹੈਂਡਲਰ - ਵਰਕਰ - ਨੂੰ ਬਿਲਡ ਏਜੰਟ ਨੂੰ ਭੇਜਦਾ ਹੈ, ਤਾਂ ਇਹ ਇਸਨੂੰ ਵੇਰੀਏਬਲਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਵੀ ਦਿੰਦਾ ਹੈ ਜੋ ਹੈਂਡਲਰ ਪ੍ਰਕਿਰਿਆ ਦੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਖਤਮ ਹੁੰਦੇ ਹਨ। ਇਹਨਾਂ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲਾਂ ਵਿੱਚ ਬਿਲਡ ਨਾਮ, ਸੰਸਕਰਣ ਨਾਮ ਅਤੇ ਹੋਰ ਵੇਰੀਏਬਲ ਹੁੰਦੇ ਹਨ। "ਇੱਕ RPM ਪੈਕੇਜ ਬਣਾਉਣਾ" ਭਾਗ ਵਿੱਚ ਇਸ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹੋ।
TFS ਸਥਾਪਤ ਕਰਨਾ ਪਾਈਪਲਾਈਨ ਵਿਛਾਉਣ ਲਈ ਉਤਰੇ ਹਨ। ਪਹਿਲਾਂ, ਅਸੀਂ ਵਿੰਡੋਜ਼ ਏਜੰਟਾਂ 'ਤੇ ਸਾਰੇ ਵਿੰਡੋਜ਼ ਪ੍ਰੋਜੈਕਟ ਇਕੱਠੇ ਕੀਤੇ ਸਨ, ਪਰ ਹੁਣ ਇੱਕ ਲੀਨਕਸ ਏਜੰਟ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ - ਇੱਕ ਬਿਲਡ ਏਜੰਟ, ਜਿਸ ਨੂੰ ਬਿਲਡ ਗਰੁੱਪ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਕੁਝ ਕਲਾਤਮਕ ਚੀਜ਼ਾਂ ਨਾਲ ਭਰਪੂਰ, ਅਤੇ ਦੱਸਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਇਸ ਬਿਲਡ ਏਜੰਟ 'ਤੇ ਕਿਸ ਕਿਸਮ ਦੇ ਪ੍ਰੋਜੈਕਟ ਬਣਾਏ ਜਾਣਗੇ। , ਅਤੇ ਕਿਸੇ ਤਰ੍ਹਾਂ ਪਾਈਪਲਾਈਨ ਨੂੰ ਸੋਧੋ।
ਪਛਾਣ ਸਰਵਰ। ADFS ਸਾਡਾ ਤਰੀਕਾ ਨਹੀਂ ਹੈ, ਅਸੀਂ ਓਪਨ ਸੋਰਸ ਲਈ ਜਾ ਰਹੇ ਹਾਂ।
ਆਉ ਭਾਗਾਂ ਵਿੱਚੋਂ ਲੰਘੀਏ.
ਮੈਜਿਕ ਬਾਕਸ
ਚਾਰ ਭਾਗਾਂ ਦੇ ਸ਼ਾਮਲ ਹਨ।
ਲੀਨਕਸ ਬਿਲਡ ਏਜੰਟ। ਲੀਨਕਸ, ਕਿਉਂਕਿ ਅਸੀਂ ਇਸਦੇ ਲਈ ਬਣਾਉਂਦੇ ਹਾਂ - ਇਹ ਤਰਕਪੂਰਨ ਹੈ। ਇਹ ਭਾਗ ਤਿੰਨ ਪੜਾਵਾਂ ਵਿੱਚ ਕੀਤਾ ਗਿਆ ਸੀ।
- ਵਰਕਰਾਂ ਦੀ ਸੰਰਚਨਾ ਕਰੋ ਅਤੇ ਇਕੱਲੇ ਨਹੀਂ, ਕਿਉਂਕਿ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਵੰਡੇ ਕੰਮ ਦੀ ਉਮੀਦ ਕੀਤੀ ਗਈ ਸੀ।
- .NET ਕੋਰ 1.x ਨੂੰ ਸਥਾਪਿਤ ਕਰੋ. ਕਿਉਂ 1.x ਜਦੋਂ 2.0 ਪਹਿਲਾਂ ਹੀ ਸਟੈਂਡਰਡ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਉਪਲਬਧ ਹੈ? ਕਿਉਂਕਿ ਜਦੋਂ ਅਸੀਂ ਵਿਕਾਸ ਸ਼ੁਰੂ ਕੀਤਾ, ਸਥਿਰ ਸੰਸਕਰਣ 1.09 ਸੀ, ਅਤੇ ਇਸ ਦੇ ਅਧਾਰ ਤੇ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਗਿਆ ਸੀ।
- Git 2.x.
RPM-ਰਿਪੋਜ਼ਟਰੀ। RPM ਪੈਕੇਜਾਂ ਨੂੰ ਕਿਤੇ ਸਟੋਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਮੰਨਿਆ ਗਿਆ ਸੀ ਕਿ ਅਸੀਂ ਉਹੀ ਕਾਰਪੋਰੇਟ RPM ਰਿਪੋਜ਼ਟਰੀ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ ਜੋ ਸਾਰੇ ਲੀਨਕਸ ਹੋਸਟਾਂ ਲਈ ਉਪਲਬਧ ਹੈ। ਉਨ੍ਹਾਂ ਨੇ ਅਜਿਹਾ ਹੀ ਕੀਤਾ। ਰਿਪੋਜ਼ਟਰੀ ਸਰਵਰ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ ਵੈੱਬਹੁੱਕ ਜਿਸ ਨੇ ਨਿਰਧਾਰਤ ਸਥਾਨ ਤੋਂ ਲੋੜੀਂਦੇ RPM ਪੈਕੇਜ ਨੂੰ ਡਾਊਨਲੋਡ ਕੀਤਾ ਹੈ। ਪੈਕੇਜ ਸੰਸਕਰਣ ਦੀ ਰਿਪੋਰਟ ਬਿਲਡ ਏਜੰਟ ਦੁਆਰਾ ਵੈਬਹੁੱਕ ਨੂੰ ਕੀਤੀ ਗਈ ਸੀ।
ਗੀਟਲੈਬ. ਧਿਆਨ ਦਿਓ! ਇੱਥੇ GitLab ਦੀ ਵਰਤੋਂ ਡਿਵੈਲਪਰਾਂ ਦੁਆਰਾ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ, ਪਰ ਕਾਰਜ ਵਿਭਾਗ ਦੁਆਰਾ ਐਪਲੀਕੇਸ਼ਨ ਸੰਸਕਰਣਾਂ, ਪੈਕੇਜ ਸੰਸਕਰਣਾਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ, ਸਾਰੀਆਂ ਲੀਨਕਸ ਮਸ਼ੀਨਾਂ ਦੀ ਸਥਿਤੀ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇਹ ਵਿਅੰਜਨ ਨੂੰ ਸਟੋਰ ਕਰਦੀ ਹੈ - ਸਾਰੇ ਕਠਪੁਤਲੀ ਪ੍ਰਗਟ ਹੁੰਦੇ ਹਨ।
ਕਠਪੁਤਲੀ - ਸਾਰੇ ਵਿਵਾਦਪੂਰਨ ਮੁੱਦਿਆਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ ਅਤੇ ਬਿਲਕੁਲ ਉਹੀ ਸੰਰਚਨਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਅਸੀਂ ਗਿਟਲੈਬ ਤੋਂ ਚਾਹੁੰਦੇ ਹਾਂ।
ਅਸੀਂ ਡੁਬਕੀ ਲਗਾਉਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ। RPM ਨੂੰ DLL ਡਿਲੀਵਰੀ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ?
RPM ਨੂੰ DDL ਡਿਲੀਵਰੀ
ਮੰਨ ਲਓ ਕਿ ਸਾਡੇ ਕੋਲ .NET ਵਿਕਾਸ ਰੌਕ ਸਟਾਰ ਹੈ। ਇਹ ਵਿਜ਼ੂਅਲ ਸਟੂਡੀਓ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਰੀਲੀਜ਼ ਸ਼ਾਖਾ ਬਣਾਉਂਦਾ ਹੈ। ਉਸ ਤੋਂ ਬਾਅਦ, ਇਹ ਇਸਨੂੰ Git 'ਤੇ ਅੱਪਲੋਡ ਕਰਦਾ ਹੈ, ਅਤੇ Git ਇੱਥੇ ਇੱਕ TFS ਇਕਾਈ ਹੈ, ਯਾਨੀ ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਰਿਪੋਜ਼ਟਰੀ ਹੈ ਜਿਸ ਨਾਲ ਡਿਵੈਲਪਰ ਕੰਮ ਕਰਦਾ ਹੈ।
ਜਿਸ ਤੋਂ ਬਾਅਦ TFS ਦੇਖਦਾ ਹੈ ਕਿ ਇੱਕ ਨਵੀਂ ਪ੍ਰਤੀਬੱਧਤਾ ਆ ਗਈ ਹੈ। ਕਿਹੜੀ ਐਪ? TFS ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਇੱਕ ਲੇਬਲ ਹੁੰਦਾ ਹੈ ਜੋ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਇੱਕ ਖਾਸ ਬਿਲਡ ਏਜੰਟ ਕੋਲ ਕਿਹੜੇ ਸਰੋਤ ਹਨ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਉਹ ਦੇਖਦਾ ਹੈ ਕਿ ਅਸੀਂ ਇੱਕ .NET ਕੋਰ ਪ੍ਰੋਜੈਕਟ ਬਣਾ ਰਹੇ ਹਾਂ ਅਤੇ ਪੂਲ ਵਿੱਚੋਂ ਇੱਕ ਲੀਨਕਸ ਬਿਲਡ ਏਜੰਟ ਦੀ ਚੋਣ ਕਰਦਾ ਹੈ।
ਬਿਲਡ ਏਜੰਟ ਸਰੋਤਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਲੋੜੀਂਦੇ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ ਨਿਰਭਰਤਾ .NET ਰਿਪੋਜ਼ਟਰੀ, npm, ਆਦਿ ਤੋਂ। ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਪੈਕੇਜਿੰਗ, RPM ਪੈਕੇਜ ਨੂੰ RPM ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਭੇਜਦਾ ਹੈ।
ਦੂਜੇ ਪਾਸੇ, ਹੇਠ ਲਿਖਿਆਂ ਵਾਪਰਦਾ ਹੈ. ਓਪਰੇਸ਼ਨ ਡਿਪਾਰਟਮੈਂਟ ਇੰਜੀਨੀਅਰ ਪ੍ਰੋਜੈਕਟ ਦੇ ਰੋਲਆਊਟ ਵਿੱਚ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ: ਉਹ ਪੈਕੇਜਾਂ ਦੇ ਸੰਸਕਰਣਾਂ ਨੂੰ ਬਦਲਦਾ ਹੈ ਹੀਰਾ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਜਿੱਥੇ ਐਪਲੀਕੇਸ਼ਨ ਰੈਸਿਪੀ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਕਠਪੁਤਲੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਯੱਮ, ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਨਵਾਂ ਪੈਕੇਜ ਲਿਆਉਂਦਾ ਹੈ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਨਵਾਂ ਸੰਸਕਰਣ ਵਰਤਣ ਲਈ ਤਿਆਰ ਹੈ।
ਸ਼ਬਦਾਂ ਵਿਚ ਸਭ ਕੁਝ ਸਧਾਰਨ ਹੈ, ਪਰ ਬਿਲਡ ਏਜੰਟ ਦੇ ਅੰਦਰ ਕੀ ਹੁੰਦਾ ਹੈ?
ਪੈਕੇਜਿੰਗ DLL RPM
TFS ਤੋਂ ਪ੍ਰੋਜੈਕਟ ਸਰੋਤ ਅਤੇ ਬਿਲਡ ਟਾਸਕ ਪ੍ਰਾਪਤ ਕੀਤੇ। ਏਜੰਟ ਬਣਾਓ ਸਰੋਤਾਂ ਤੋਂ ਹੀ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ. ਅਸੈਂਬਲ ਕੀਤਾ ਪ੍ਰੋਜੈਕਟ ਇੱਕ ਸੈੱਟ ਦੇ ਰੂਪ ਵਿੱਚ ਉਪਲਬਧ ਹੈ DLL ਫਾਈਲਾਂ, ਜੋ ਕਿ ਫਾਈਲ ਸਿਸਟਮ ਉੱਤੇ ਲੋਡ ਨੂੰ ਘਟਾਉਣ ਲਈ ਇੱਕ ਜ਼ਿਪ ਆਰਕਾਈਵ ਵਿੱਚ ਪੈਕ ਕੀਤੇ ਗਏ ਹਨ।
ਜ਼ਿਪ ਆਰਕਾਈਵ ਨੂੰ ਸੁੱਟ ਦਿੱਤਾ ਗਿਆ ਹੈ RPM ਪੈਕੇਜ ਬਿਲਡ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ। ਅੱਗੇ, Bash ਸਕ੍ਰਿਪਟ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲਾਂ ਨੂੰ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ, ਬਿਲਡ ਸੰਸਕਰਣ, ਪ੍ਰੋਜੈਕਟ ਸੰਸਕਰਣ, ਬਿਲਡ ਡਾਇਰੈਕਟਰੀ ਦਾ ਮਾਰਗ ਲੱਭਦੀ ਹੈ, ਅਤੇ RPM-ਬਿਲਡ ਨੂੰ ਚਲਾਉਂਦੀ ਹੈ। ਇੱਕ ਵਾਰ ਬਿਲਡ ਪੂਰਾ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਪੈਕੇਜ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਸਥਾਨਕ ਭੰਡਾਰ, ਜੋ ਕਿ ਬਿਲਡ ਏਜੰਟ 'ਤੇ ਸਥਿਤ ਹੈ।
ਅੱਗੇ, ਬਿਲਡ ਏਜੰਟ ਤੋਂ RPM ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਸਰਵਰ ਤੱਕ JSON ਬੇਨਤੀ ਭੇਜੀ ਗਈ ਹੈ ਸੰਸਕਰਣ ਅਤੇ ਬਿਲਡ ਦੇ ਨਾਮ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਵੈਬਹੁੱਕ, ਜਿਸ ਬਾਰੇ ਮੈਂ ਪਹਿਲਾਂ ਗੱਲ ਕੀਤੀ ਸੀ, ਬਿਲਡ ਏਜੰਟ 'ਤੇ ਸਥਾਨਕ ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਇਹ ਬਹੁਤ ਹੀ ਪੈਕੇਜ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ ਅਤੇ ਨਵੀਂ ਅਸੈਂਬਲੀ ਨੂੰ ਇੰਸਟਾਲੇਸ਼ਨ ਲਈ ਉਪਲਬਧ ਬਣਾਉਂਦਾ ਹੈ।
RPM ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਇਹ ਖਾਸ ਪੈਕੇਜ ਡਿਲੀਵਰੀ ਸਕੀਮ ਕਿਉਂ? ਮੈਂ ਇਕੱਠੇ ਕੀਤੇ ਪੈਕੇਜ ਨੂੰ ਤੁਰੰਤ ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਕਿਉਂ ਨਹੀਂ ਭੇਜ ਸਕਦਾ? ਤੱਥ ਇਹ ਹੈ ਕਿ ਇਹ ਸੁਰੱਖਿਆ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਇੱਕ ਸ਼ਰਤ ਹੈ. ਇਹ ਦ੍ਰਿਸ਼ ਅਣਅਧਿਕਾਰਤ ਲੋਕਾਂ ਦੁਆਰਾ RPM ਪੈਕੇਜਾਂ ਨੂੰ ਸਰਵਰ ਉੱਤੇ ਅੱਪਲੋਡ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ ਜੋ ਸਾਰੀਆਂ ਲੀਨਕਸ ਮਸ਼ੀਨਾਂ ਲਈ ਪਹੁੰਚਯੋਗ ਹੈ।
ਡਾਟਾਬੇਸ ਸੰਸਕਰਣ
ਵਿਕਾਸ ਟੀਮ ਨਾਲ ਸਲਾਹ-ਮਸ਼ਵਰੇ 'ਤੇ, ਇਹ ਪਤਾ ਲੱਗਾ ਕਿ ਮੁੰਡੇ MS SQL ਦੇ ਨੇੜੇ ਸਨ, ਪਰ ਜ਼ਿਆਦਾਤਰ ਗੈਰ-ਵਿੰਡੋਜ਼ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਆਪਣੀ ਪੂਰੀ ਤਾਕਤ ਨਾਲ PostgreSQL ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਸੀ। ਕਿਉਂਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਭੁਗਤਾਨ ਕੀਤੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਛੱਡਣ ਦਾ ਫੈਸਲਾ ਕਰ ਲਿਆ ਸੀ, ਅਸੀਂ ਇੱਥੇ ਵੀ PostgreSQL ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ ਹੈ।
ਇਸ ਹਿੱਸੇ ਵਿੱਚ ਮੈਂ ਤੁਹਾਨੂੰ ਦੱਸਣਾ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਅਸੀਂ ਡੇਟਾਬੇਸ ਦਾ ਸੰਸਕਰਣ ਕਿਵੇਂ ਕੀਤਾ ਅਤੇ ਅਸੀਂ ਫਲਾਈਵੇ ਅਤੇ ਐਂਟਿਟੀ ਫਰੇਮਵਰਕ ਕੋਰ ਦੇ ਵਿਚਕਾਰ ਕਿਵੇਂ ਚੁਣਿਆ। ਆਓ ਉਨ੍ਹਾਂ ਦੇ ਫਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨਾਂ ਨੂੰ ਵੇਖੀਏ.
Минусы
ਫਲਾਈਵੇ ਸਿਰਫ ਇੱਕ ਪਾਸੇ ਜਾਂਦਾ ਹੈ, ਅਸੀਂ ਅਸੀਂ ਪਿੱਛੇ ਨਹੀਂ ਹਟ ਸਕਦੇ - ਇਹ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਨੁਕਸਾਨ ਹੈ. ਤੁਸੀਂ ਇਸਦੀ ਤੁਲਨਾ ਹੋਰ ਤਰੀਕਿਆਂ ਨਾਲ ਐਂਟਿਟੀ ਫਰੇਮਵਰਕ ਕੋਰ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ - ਡਿਵੈਲਪਰ ਦੀ ਸਹੂਲਤ ਦੇ ਰੂਪ ਵਿੱਚ। ਤੁਹਾਨੂੰ ਯਾਦ ਹੈ ਕਿ ਅਸੀਂ ਇਸਨੂੰ ਸਭ ਤੋਂ ਅੱਗੇ ਰੱਖਦੇ ਹਾਂ, ਅਤੇ ਮੁੱਖ ਮਾਪਦੰਡ ਵਿੰਡੋਜ਼ ਦੇ ਵਿਕਾਸ ਲਈ ਕੁਝ ਵੀ ਬਦਲਣਾ ਨਹੀਂ ਸੀ।
Flyway ਸਾਡੇ ਲਈ ਕਿਸੇ ਕਿਸਮ ਦੇ ਰੈਪਰ ਦੀ ਲੋੜ ਸੀਤਾਂ ਜੋ ਮੁੰਡੇ ਨਾ ਲਿਖਣ SQL ਸਵਾਲ. ਉਹ OOP ਸ਼ਬਦਾਂ ਵਿੱਚ ਕੰਮ ਕਰਨ ਦੇ ਬਹੁਤ ਨੇੜੇ ਹਨ। ਅਸੀਂ ਡੇਟਾਬੇਸ ਵਸਤੂਆਂ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਨਿਰਦੇਸ਼ ਲਿਖੇ, ਇੱਕ SQL ਪੁੱਛਗਿੱਛ ਤਿਆਰ ਕੀਤੀ ਅਤੇ ਇਸਨੂੰ ਚਲਾਇਆ। ਡਾਟਾਬੇਸ ਦਾ ਨਵਾਂ ਸੰਸਕਰਣ ਤਿਆਰ ਹੈ, ਟੈਸਟ ਕੀਤਾ ਗਿਆ ਹੈ - ਸਭ ਕੁਝ ਠੀਕ ਹੈ, ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ।
ਇਕਾਈ ਫਰੇਮਵਰਕ ਕੋਰ ਵਿੱਚ ਇੱਕ ਮਾਇਨਸ ਹੈ - ਇਸ ਨੂੰ ਭਾਰੀ ਬੋਝ ਹੇਠ ਸਬ-ਅਨੁਕੂਲ SQL ਸਵਾਲ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਕਮੀ ਮਹੱਤਵਪੂਰਨ ਹੋ ਸਕਦੀ ਹੈ। ਪਰ ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਉੱਚ-ਲੋਡ ਸੇਵਾ ਨਹੀਂ ਹੈ, ਅਸੀਂ ਸੈਂਕੜੇ RPS ਵਿੱਚ ਲੋਡ ਦੀ ਗਣਨਾ ਨਹੀਂ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਇਹਨਾਂ ਜੋਖਮਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਲਿਆ ਹੈ ਅਤੇ ਸਮੱਸਿਆ ਨੂੰ ਭਵਿੱਖ ਵਿੱਚ ਸੌਂਪ ਦਿੱਤਾ ਹੈ।
Плюсы
ਇਕਾਈ ਫਰੇਮਵਰਕ ਕੋਰ ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਵਿਕਾਸ ਕਰਨਾ ਆਸਾਨ ਹੈ, ਅਤੇ ਫਲਾਈਵੇਅ ਮੌਜੂਦਾ CI ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਏਕੀਕ੍ਰਿਤ. ਪਰ ਅਸੀਂ ਇਸਨੂੰ ਡਿਵੈਲਪਰਾਂ ਲਈ ਸੁਵਿਧਾਜਨਕ ਬਣਾਉਂਦੇ ਹਾਂ :)
ਰੋਲ-ਅੱਪ ਵਿਧੀ
ਕਠਪੁਤਲੀ ਦੇਖਦੀ ਹੈ ਕਿ ਪੈਕੇਜ ਸੰਸਕਰਣ ਵਿੱਚ ਇੱਕ ਤਬਦੀਲੀ ਆ ਰਹੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਉਹ ਵੀ ਸ਼ਾਮਲ ਹੈ ਜੋ ਮਾਈਗ੍ਰੇਸ਼ਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਪਹਿਲਾਂ, ਇਹ ਇੱਕ ਪੈਕੇਜ ਸਥਾਪਤ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਕ੍ਰਿਪਟਾਂ ਅਤੇ ਡੇਟਾਬੇਸ-ਸਬੰਧਤ ਕਾਰਜਸ਼ੀਲਤਾ ਹੁੰਦੀ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ, ਡੇਟਾਬੇਸ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ. ਅੱਗੇ ਬਾਕੀ ਬਚੇ ਭਾਗਾਂ ਦੀ ਸਥਾਪਨਾ ਆਉਂਦੀ ਹੈ. ਜਿਸ ਕ੍ਰਮ ਵਿੱਚ ਪੈਕੇਜ ਸਥਾਪਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਲਾਂਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਉਸ ਦਾ ਵਰਣਨ ਕਠਪੁਤਲੀ ਮੈਨੀਫੈਸਟ ਵਿੱਚ ਕੀਤਾ ਗਿਆ ਹੈ।
ਐਪਲੀਕੇਸ਼ਨਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਟੋਕਨ, ਡੇਟਾਬੇਸ ਪਾਸਵਰਡ, ਇਹ ਸਭ ਕੁਝ ਕਠਪੁਤਲੀ ਮਾਸਟਰ ਤੋਂ ਸੰਰਚਨਾ ਵਿੱਚ ਖਿੱਚਿਆ ਜਾਂਦਾ ਹੈ, ਜਿੱਥੇ ਉਹਨਾਂ ਨੂੰ ਐਨਕ੍ਰਿਪਟਡ ਰੂਪ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
TFS ਸਮੱਸਿਆਵਾਂ
ਜਦੋਂ ਅਸੀਂ ਫੈਸਲਾ ਕੀਤਾ ਅਤੇ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਸਭ ਕੁਝ ਸਾਡੇ ਲਈ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ, ਮੈਂ ਇਹ ਦੇਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਕਿ TFS ਵਿੱਚ ਅਸੈਂਬਲੀਆਂ ਦੇ ਨਾਲ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਵਿਨ ਡਿਵੈਲਪਮੈਂਟ ਡਿਪਾਰਟਮੈਂਟ ਲਈ ਹੋਰ ਪ੍ਰੋਜੈਕਟਾਂ 'ਤੇ - ਕੀ ਅਸੀਂ ਜਲਦੀ ਬਣਾ ਰਹੇ/ਰਿਲੀਜ਼ ਕਰ ਰਹੇ ਹਾਂ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਗਤੀ ਦੇ ਨਾਲ ਮਹੱਤਵਪੂਰਨ ਸਮੱਸਿਆਵਾਂ ਲੱਭੀਆਂ।
ਮੁੱਖ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਇਕੱਠੇ ਹੋਣ ਵਿੱਚ 12-15 ਮਿੰਟ ਲੱਗਦੇ ਹਨ - ਇਹ ਬਹੁਤ ਲੰਬਾ ਸਮਾਂ ਹੈ, ਤੁਸੀਂ ਇਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਰਹਿ ਸਕਦੇ। ਇੱਕ ਤੇਜ਼ ਵਿਸ਼ਲੇਸ਼ਣ ਨੇ I/O ਵਿੱਚ ਇੱਕ ਭਿਆਨਕ ਕਮੀ ਦਿਖਾਈ, ਅਤੇ ਇਹ ਐਰੇ 'ਤੇ ਸੀ।
ਕੰਪੋਨੈਂਟ ਦੁਆਰਾ ਇਸਦੇ ਹਿੱਸੇ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਤਿੰਨ ਫੋਸੀ ਦੀ ਪਛਾਣ ਕੀਤੀ. ਪਹਿਲਾਂ - "ਕੈਸਪਰਸਕੀ ਐਂਟੀਵਾਇਰਸ", ਜੋ ਸਾਰੇ ਵਿੰਡੋਜ਼ ਬਿਲਡ ਏਜੰਟਾਂ 'ਤੇ ਸਰੋਤਾਂ ਨੂੰ ਸਕੈਨ ਕਰਦਾ ਹੈ। ਦੂਜਾ - Windows ਨੂੰ ਇੰਡੈਕਸਰ। ਇਹ ਅਯੋਗ ਨਹੀਂ ਸੀ, ਅਤੇ ਤੈਨਾਤੀ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ ਬਿਲਡ ਏਜੰਟਾਂ 'ਤੇ ਸਭ ਕੁਝ ਰੀਅਲ ਟਾਈਮ ਵਿੱਚ ਸੂਚੀਬੱਧ ਕੀਤਾ ਗਿਆ ਸੀ।
ਤੀਜਾ - Npm ਇੰਸਟਾਲ. ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਜ਼ਿਆਦਾਤਰ ਪਾਈਪਲਾਈਨਾਂ ਵਿੱਚ ਅਸੀਂ ਇਸ ਸਹੀ ਦ੍ਰਿਸ਼ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ। ਉਹ ਬੁਰਾ ਕਿਉਂ ਹੈ? Npm ਸਥਾਪਨਾ ਪ੍ਰਕਿਰਿਆ ਉਦੋਂ ਚਲਾਈ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਨਿਰਭਰਤਾ ਟ੍ਰੀ ਬਣ ਜਾਂਦਾ ਹੈ package-lock.json, ਜਿੱਥੇ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਣ ਲਈ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਪੈਕੇਜਾਂ ਦੇ ਸੰਸਕਰਣਾਂ ਨੂੰ ਰਿਕਾਰਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਨਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ Npm install ਹਰ ਵਾਰ ਇੰਟਰਨੈਟ ਤੋਂ ਪੈਕੇਜਾਂ ਦੇ ਨਵੀਨਤਮ ਸੰਸਕਰਣਾਂ ਨੂੰ ਖਿੱਚਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਵੱਡੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਇਸ ਵਿੱਚ ਬਹੁਤ ਸਮਾਂ ਲੱਗਦਾ ਹੈ।
ਡਿਵੈਲਪਰ ਕਦੇ-ਕਦਾਈਂ ਇਹ ਟੈਸਟ ਕਰਨ ਲਈ ਸਥਾਨਕ ਮਸ਼ੀਨ 'ਤੇ ਪ੍ਰਯੋਗ ਕਰਦੇ ਹਨ ਕਿ ਕੋਈ ਖਾਸ ਹਿੱਸਾ ਜਾਂ ਪੂਰਾ ਪ੍ਰੋਜੈਕਟ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਕਈ ਵਾਰੀ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਸਭ ਕੁਝ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਠੰਡਾ ਸੀ, ਪਰ ਉਨ੍ਹਾਂ ਨੇ ਇਸ ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ, ਇਸਨੂੰ ਰੋਲ ਆਊਟ ਕੀਤਾ, ਅਤੇ ਕੁਝ ਵੀ ਕੰਮ ਨਹੀਂ ਕੀਤਾ. ਅਸੀਂ ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ ਕਿ ਸਮੱਸਿਆ ਕੀ ਹੈ - ਹਾਂ, ਨਿਰਭਰਤਾ ਵਾਲੇ ਪੈਕੇਜਾਂ ਦੇ ਵੱਖ-ਵੱਖ ਸੰਸਕਰਣ।
ਫੈਸਲੇ ਦਾ
- AV ਅਪਵਾਦਾਂ ਵਿੱਚ ਸਰੋਤ।
- ਇੰਡੈਕਸਿੰਗ ਨੂੰ ਅਸਮਰੱਥ ਬਣਾਓ।
- ਵੱਲ ਜਾ npm ci.
npm ci ਦੇ ਫਾਇਦੇ ਇਹ ਹਨ ਕਿ ਅਸੀਂ ਅਸੀਂ ਇੱਕ ਵਾਰ ਨਿਰਭਰਤਾ ਦੇ ਰੁੱਖ ਨੂੰ ਇਕੱਠਾ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਸਾਨੂੰ ਡਿਵੈਲਪਰ ਪ੍ਰਦਾਨ ਕਰਨ ਦਾ ਮੌਕਾ ਮਿਲਦਾ ਹੈ ਪੈਕੇਜਾਂ ਦੀ ਮੌਜੂਦਾ ਸੂਚੀ, ਜਿਸ ਨਾਲ ਉਹ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਜਿੰਨਾ ਚਾਹੇ ਪ੍ਰਯੋਗ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੈ ਡਿਵੈਲਪਰ ਜੋ ਕੋਡ ਲਿਖਦੇ ਹਨ।
ਕੌਨਫਿਗਰੇਸ਼ਨ
ਹੁਣ ਰਿਪੋਜ਼ਟਰੀ ਸੰਰਚਨਾ ਬਾਰੇ ਥੋੜਾ ਜਿਹਾ. ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ ਅਸੀਂ ਵਰਤਦੇ ਹਾਂ ਗਠਜੋੜ ਰਿਪੋਜ਼ਟਰੀਆਂ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ, ਸਮੇਤ ਅੰਦਰੂਨੀ REPO. ਇਸ ਅੰਦਰੂਨੀ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਉਹ ਸਾਰੇ ਹਿੱਸੇ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ ਜੋ ਅਸੀਂ ਅੰਦਰੂਨੀ ਉਦੇਸ਼ਾਂ ਲਈ ਵਰਤਦੇ ਹਾਂ, ਉਦਾਹਰਨ ਲਈ, ਸਵੈ-ਲਿਖਤ ਨਿਗਰਾਨੀ।
ਅਸੀਂ ਵੀ ਵਰਤਦੇ ਹਾਂ ਨੂਗੇਟ, ਕਿਉਂਕਿ ਇਸ ਵਿੱਚ ਹੋਰ ਪੈਕੇਜ ਮੈਨੇਜਰਾਂ ਦੇ ਮੁਕਾਬਲੇ ਬਿਹਤਰ ਕੈਸ਼ਿੰਗ ਹੈ।
ਇਸ ਦਾ ਨਤੀਜਾ
ਸਾਡੇ ਦੁਆਰਾ ਬਿਲਡ ਏਜੰਟਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ, ਔਸਤ ਬਿਲਡ ਸਮਾਂ 12 ਮਿੰਟ ਤੋਂ ਘਟਾ ਕੇ 7 ਕਰ ਦਿੱਤਾ ਗਿਆ ਸੀ।
ਜੇਕਰ ਅਸੀਂ ਉਹਨਾਂ ਸਾਰੀਆਂ ਮਸ਼ੀਨਾਂ ਨੂੰ ਗਿਣਦੇ ਹਾਂ ਜੋ ਅਸੀਂ ਵਿੰਡੋਜ਼ ਲਈ ਵਰਤ ਸਕਦੇ ਸੀ, ਪਰ ਇਸ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਲੀਨਕਸ ਵਿੱਚ ਬਦਲੀ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਲਗਭਗ $10 ਦੀ ਬਚਤ ਕਰਦੇ ਹਾਂ। ਅਤੇ ਇਹ ਸਿਰਫ਼ ਲਾਇਸੈਂਸਾਂ 'ਤੇ ਹੈ, ਅਤੇ ਹੋਰ ਵੀ ਜੇਕਰ ਅਸੀਂ ਸਮੱਗਰੀ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹਾਂ।
ਯੋਜਨਾਵਾਂ
ਅਗਲੀ ਤਿਮਾਹੀ ਲਈ, ਅਸੀਂ ਕੋਡ ਡਿਲੀਵਰੀ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ 'ਤੇ ਕੰਮ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਈ ਹੈ।
ਪ੍ਰੀਬਿਲਡ ਡੌਕਰ ਚਿੱਤਰ 'ਤੇ ਸਵਿਚ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ. TFS ਬਹੁਤ ਸਾਰੇ ਪਲੱਗਇਨਾਂ ਨਾਲ ਇੱਕ ਵਧੀਆ ਚੀਜ਼ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਇੱਕ ਡੌਕਰ ਚਿੱਤਰ ਦੀ ਟਰਿੱਗਰ-ਅਧਾਰਿਤ ਅਸੈਂਬਲੀ ਵੀ ਸ਼ਾਮਲ ਹੈ। ਅਸੀਂ ਇਸ ਟਰਿੱਗਰ ਨੂੰ ਉਸੇ ਲਈ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ package-lock.json. ਜੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਬਣਾਉਣ ਲਈ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਭਾਗਾਂ ਦੀ ਰਚਨਾ ਕਿਸੇ ਤਰ੍ਹਾਂ ਬਦਲ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਅਸੀਂ ਇੱਕ ਨਵਾਂ ਡੌਕਰ ਚਿੱਤਰ ਬਣਾਉਂਦੇ ਹਾਂ। ਇਸਨੂੰ ਬਾਅਦ ਵਿੱਚ ਅਸੈਂਬਲ ਕੀਤੀ ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ ਕੰਟੇਨਰ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਹੁਣ ਮਾਮਲਾ ਨਹੀਂ ਹੈ, ਪਰ ਅਸੀਂ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਇੱਕ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਜਾਣ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ, ਜੋ ਸਾਡੀ ਕੰਪਨੀ ਵਿੱਚ ਸਰਗਰਮੀ ਨਾਲ ਵਿਕਾਸ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਉਤਪਾਦਨ ਹੱਲ ਪ੍ਰਦਾਨ ਕਰ ਰਿਹਾ ਹੈ।
ਸੰਖੇਪ
ਮੈਂ ਹਰ ਕਿਸੇ ਨੂੰ ਵਿੰਡੋਜ਼ ਨੂੰ ਸੁੱਟਣ ਲਈ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹਾਂ, ਪਰ ਅਜਿਹਾ ਇਸ ਲਈ ਨਹੀਂ ਹੈ ਕਿਉਂਕਿ ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਇਸਨੂੰ ਕਿਵੇਂ ਪਕਾਉਣਾ ਹੈ। ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਜ਼ਿਆਦਾਤਰ ਓਪਨਸੋਰਸ ਹੱਲ ਹਨ ਲੀਨਕਸ ਸਟੈਕ. ਕੀ ਤੁਸੀਂ ਠੀਕ ਹੋ ਸਰੋਤ 'ਤੇ ਬਚਾਓ. ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਭਵਿੱਖ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਭਾਈਚਾਰੇ ਦੇ ਨਾਲ ਲੀਨਕਸ ਉੱਤੇ ਓਪਨ ਸੋਰਸ ਹੱਲਾਂ ਦਾ ਹੈ.
ਅਲੈਗਜ਼ੈਂਡਰ ਸਿੰਚਿਨੋਵ ਦਾ ਸਪੀਕਰ ਪ੍ਰੋਫਾਈਲ .
ਪੇਸ਼ੇਵਰਾਂ ਦੁਆਰਾ ਪੇਸ਼ੇਵਰਾਂ ਲਈ ਵਿਕਾਸ, ਟੈਸਟਿੰਗ ਅਤੇ ਸੰਚਾਲਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਏਕੀਕਰਣ 'ਤੇ ਇੱਕ ਕਾਨਫਰੰਸ ਹੈ। ਇਸ ਲਈ ਉਹ ਪ੍ਰੋਜੈਕਟ ਜਿਸ ਬਾਰੇ ਅਲੈਗਜ਼ੈਂਡਰ ਨੇ ਗੱਲ ਕੀਤੀ ਸੀ? ਲਾਗੂ ਕੀਤਾ ਅਤੇ ਕੰਮ ਕੀਤਾ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਦਿਨ ਦੋ ਸਫਲ ਰੀਲੀਜ਼ ਹੋਏ। 'ਤੇ 27 ਅਤੇ 28 ਮਈ ਨੂੰ ਪ੍ਰੈਕਟੀਸ਼ਨਰਾਂ ਵੱਲੋਂ ਹੋਰ ਵੀ ਅਜਿਹੇ ਹੀ ਮਾਮਲੇ ਸਾਹਮਣੇ ਆਉਣਗੇ। ਤੁਸੀਂ ਅਜੇ ਵੀ ਆਖਰੀ ਗੱਡੀ ਵਿੱਚ ਛਾਲ ਮਾਰ ਸਕਦੇ ਹੋ ਅਤੇ ਜਾਂ ਆਪਣਾ ਸਮਾਂ ਲਓ ਟਿਕਟ. Skolkovo ਵਿੱਚ ਸਾਨੂੰ ਮਿਲੋ!
ਸਰੋਤ: www.habr.com