ਉਦਯੋਗਿਕ ਮਸ਼ੀਨ ਸਿਖਲਾਈ: 10 ਡਿਜ਼ਾਈਨ ਸਿਧਾਂਤ

ਉਦਯੋਗਿਕ ਮਸ਼ੀਨ ਸਿਖਲਾਈ: 10 ਡਿਜ਼ਾਈਨ ਸਿਧਾਂਤ

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

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

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

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

ਸਿਧਾਂਤ 1: ਇੱਕ ਕੋਡ ਅਧਾਰ

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

ਇਹ ਸਿਧਾਂਤ ਦੱਸਦਾ ਹੈ: ਇੱਕ ਕੋਡਬੇਸ ਅਤੇ ਕਈ ਤੈਨਾਤੀਆਂ ਹਨ।

Git ਨੂੰ ਉਤਪਾਦਨ ਅਤੇ ਖੋਜ ਅਤੇ ਵਿਕਾਸ (R&D) ਦੋਵਾਂ ਵਿੱਚ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਇਸਦੀ ਵਰਤੋਂ ਅਕਸਰ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ।

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

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

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

ਸਿਧਾਂਤ 2: ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਨਿਰਭਰਤਾਵਾਂ ਦਾ ਐਲਾਨ ਕਰੋ ਅਤੇ ਅਲੱਗ-ਥਲੱਗ ਕਰੋ

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

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

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

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

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

ਉਦਾਹਰਨ ਲਈ, ਤੁਹਾਡੀ requirements.txt ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇ ਸਕਦੀ ਹੈ:

# Model Building Requirements
numpy>=1.18.1,<1.19.0
pandas>=0.25.3,<0.26.0
scikit-learn>=0.22.1,<0.23.0
joblib>=0.14.1,<0.15.0

# testing requirements
pytest>=5.3.2,<6.0.0

# packaging
setuptools>=41.4.0,<42.0.0
wheel>=0.33.6,<0.34.0

# fetching datasets
kaggle>=1.5.6,<1.6.0

ਸਿਧਾਂਤ 3: ਸੰਰਚਨਾਵਾਂ

ਕਈਆਂ ਨੇ ਕਈ ਡਿਵੈਲਪਰ ਲੋਕਾਂ ਦੀਆਂ ਕਹਾਣੀਆਂ ਸੁਣੀਆਂ ਹਨ ਜੋ ਗਲਤੀ ਨਾਲ AWS ਤੋਂ ਪਾਸਵਰਡ ਅਤੇ ਹੋਰ ਕੁੰਜੀਆਂ ਦੇ ਨਾਲ ਜਨਤਕ ਰਿਪੋਜ਼ਟਰੀਆਂ ਵਿੱਚ GitHub ਵਿੱਚ ਕੋਡ ਅੱਪਲੋਡ ਕਰ ਰਹੇ ਹਨ, ਅਗਲੇ ਦਿਨ $6000, ਜਾਂ $50000 ਦੇ ਕਰਜ਼ੇ ਨਾਲ ਜਾਗਦੇ ਹਨ।

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

ਇਸਦਾ ਇੱਕ ਵਿਕਲਪ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਵਿੱਚ ਸੰਰਚਨਾ ਨੂੰ ਸਟੋਰ ਕਰਨਾ ਹੈ। ਤੁਸੀਂ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਇੱਥੇ.

ਡੇਟਾ ਦੀਆਂ ਉਦਾਹਰਨਾਂ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲਾਂ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ:

• ਡੋਮੇਨ ਨਾਮ
• API URLs/URI's
• ਜਨਤਕ ਅਤੇ ਨਿੱਜੀ ਕੁੰਜੀਆਂ
• ਸੰਪਰਕ (ਮੇਲ, ਫ਼ੋਨ, ਆਦਿ)

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

ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਤੁਸੀਂ ਟੈਸਟ ਕਰਵਾਉਣ ਲਈ Kaggle API ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, ਸੌਫਟਵੇਅਰ ਡਾਊਨਲੋਡ ਕਰੋ ਅਤੇ ਮਾਡਲ ਨੂੰ ਚਲਾਉਣ ਵੇਲੇ ਇਹ ਟੈਸਟ ਕਰਨ ਲਈ ਕਿ ਮਾਡਲ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ), ਤਾਂ Kaggle ਤੋਂ ਪ੍ਰਾਈਵੇਟ ਕੁੰਜੀਆਂ, ਜਿਵੇਂ ਕਿ KAGGLE_USERNAME ਅਤੇ KAGGLE_KEY, ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਸਿਧਾਂਤ 4: ਤੀਜੀ ਧਿਰ ਦੀਆਂ ਸੇਵਾਵਾਂ

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

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

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

ਸਿਧਾਂਤ 5. ਬਿਲਡ, ਰੀਲੀਜ਼, ਰਨਟਾਈਮ

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

1. ਸਟੇਜ ਅਸੈਂਬਲੀਆਂ. ਤੁਸੀਂ ਆਪਣੇ ਬੇਅਰ ਕੋਡ ਨੂੰ ਵਿਅਕਤੀਗਤ ਸਰੋਤਾਂ ਨਾਲ ਇੱਕ ਅਖੌਤੀ ਪੈਕੇਜ ਵਿੱਚ ਬਦਲਦੇ ਹੋ ਜਿਸ ਵਿੱਚ ਸਾਰੇ ਲੋੜੀਂਦੇ ਕੋਡ ਅਤੇ ਡੇਟਾ ਹੁੰਦੇ ਹਨ। ਇਸ ਪੈਕੇਜ ਨੂੰ ਅਸੈਂਬਲੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ।
2. ਸਟੇਜ ਜਾਰੀ — ਇੱਥੇ ਅਸੀਂ ਆਪਣੀ ਸੰਰਚਨਾ ਨੂੰ ਅਸੈਂਬਲੀ ਨਾਲ ਜੋੜਦੇ ਹਾਂ, ਜਿਸ ਤੋਂ ਬਿਨਾਂ ਅਸੀਂ ਆਪਣਾ ਪ੍ਰੋਗਰਾਮ ਜਾਰੀ ਨਹੀਂ ਕਰ ਸਕਾਂਗੇ। ਹੁਣ ਇਹ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤਿਆਰ-ਲੌਂਚ ਰੀਲੀਜ਼ ਹੈ।
3. ਅਗਲਾ ਪੜਾਅ ਆਉਂਦਾ ਹੈ ਪੂਰਤੀ. ਇੱਥੇ ਅਸੀਂ ਆਪਣੀ ਰੀਲੀਜ਼ ਤੋਂ ਲੋੜੀਂਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਚਲਾ ਕੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਜਾਰੀ ਕਰਦੇ ਹਾਂ।

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

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

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

ਸਿਧਾਂਤ 6. ਆਪਣੇ ਮਾਡਲ ਨੂੰ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਜੋਂ ਚਲਾਓ

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

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

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

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

ਸਿਧਾਂਤ 7: ਰੀਸਾਈਕਲੇਬਿਲਟੀ

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

ਭਾਵ, ਮਾਡਲ ਦੇ ਨਾਲ ਤੁਹਾਡੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਇਹ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:

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

ਸਿਧਾਂਤ 8: ਨਿਰੰਤਰ ਤੈਨਾਤੀ/ਏਕੀਕਰਣ

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

ਇਸ ਲਈ, ਇਹ ਸਿਧਾਂਤ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਵਿਕਾਸ ਵਾਤਾਵਰਣ ਤੁਹਾਡੇ ਉਤਪਾਦਨ ਦੇ ਵਾਤਾਵਰਣ ਦੇ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਨੇੜੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਹ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ:

1. ਰਿਲੀਜ਼ ਦੇ ਸਮੇਂ ਨੂੰ ਕਈ ਵਾਰ ਘਟਾਓ
2. ਕੋਡ ਦੀ ਅਸੰਗਤਤਾ ਦੇ ਕਾਰਨ ਗਲਤੀਆਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਘਟਾਓ।
3. ਇਹ ਸਟਾਫ 'ਤੇ ਕੰਮ ਦਾ ਬੋਝ ਵੀ ਘਟਾਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਡਿਵੈਲਪਰ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਤਾਇਨਾਤ ਕਰਨ ਵਾਲੇ ਲੋਕ ਹੁਣ ਇੱਕ ਟੀਮ ਹਨ।

ਟੂਲ ਜੋ ਤੁਹਾਨੂੰ ਇਸ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ ਉਹ ਹਨ CircleCI, Travis CI, GitLab CI ਅਤੇ ਹੋਰ।

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

ਅੰਤਰ ਨੂੰ ਘੱਟ ਕਰੋ !!!

ਸਿਧਾਂਤ 9. ਤੁਹਾਡੇ ਲੌਗਸ

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

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

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

ਸਿਧਾਂਤ 10. ਟੈਸਟ!

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

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

ਡੂੰਘੇ ਸਿੱਖਣ ਦੇ ਮਾਡਲਾਂ ਲਈ ਇੱਕੋ ਬੀਜ ਸੈੱਟ ਕਰਨਾ ਨਾ ਭੁੱਲੋ ਤਾਂ ਜੋ ਉਹ ਲਗਾਤਾਰ ਵੱਖੋ-ਵੱਖ ਨਤੀਜੇ ਨਾ ਦੇਣ।

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

ਮੈਂ ਠੰਡੇ ਸਿਧਾਂਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਵੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗਾ ਜੋ ਕੋਈ ਵੀ ਚਾਹੇ ਤਾਂ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਛੱਡ ਸਕਦਾ ਹੈ.

ਸਰੋਤ: www.habr.com