ਫਰੇਮਵਰਕ ਅੱਪਡੇਟ ਰੀਰਾਈਟ ਨਾਲੋਂ ਸਸਤਾ ਲੱਗ ਸਕਦੇ ਹਨ, ਪਰ ਡਿਪੈਂਡੈਂਸੀਜ਼, ਰੀਗ੍ਰੈਸ਼ਨ, ਰੀਫੈਕਟਰ ਅਤੇ ਘਟਤੀ ਵੈਲੋਸਿਟੀ ਵਰਗੇ ਛੁਪੇ ਖ਼ਰਚ ਇਕੱਠੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਜਾਣੋ ਕਿ ਕਦੋਂ ਅੱਪਡੇਟ ਕਰੋ ਤੇ ਕਦੋਂ ਰੀਰਾਈਟ ਸਹੀ ਹੈ।
“ਸਿਰਫ਼ ਫਰੇਮਵਰਕ ਅੱਪਡੇਟ ਕਰ ਦਿਓ” ਅਕਸਰ ਸੁਰੱਖਿਅਤ ਤੇ ਸਸਤਾ ਵਿਕਲਪ ਲੱਗਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਲਗਦਾ ਹੈ: ਉਤਪਾਦ ਵਰਗੋ, ਆਰਕੀਟੈਕਚਰ ਇੱਕੋ, ਟੀਮ ਦੀ ਜਾਣਕਾਰੀ ਇੱਕੋ—ਸਿਰਫ਼ ਨਵਾਂ ਵਰਜਨ। ਸਟੇਕਹੋਲਡਰਾਂ ਨੂੰ ਵੀ ਇਹ ਰੀਰਾਈਟ ਨਾਲੋਂ ਅਸਾਨ ਲਗਦਾ ਹੈ।
ਪਰ ਇਹ ਜਿਹੜੀ ਸਹਜ ਧਾਰਨਾ ਹੈ, ਬਹੁਤ ਸਾਰੀਆਂ ਅੰਦਾਜ਼ਿਆਂ ਨੂੰ ਗਲਤ ਕਰ ਦਿੰਦੀ ਹੈ। ਫਰੇਮਵਰਕ ਅੱਪਡੇਟ ਦੇ ਖ਼ਰਚ ਅਕਸਰ ਉਸ ਗਿਣਤੀ ਨਾਲ ਨਹੀਂ ਚਲਦੇ ਕਿ ਕਿੰਨੀਆਂ ਫਾਇਲਾਂ 'ਤੇ ਕੰਮ ਕੀਤਾ ਗਿਆ। ਇਹ ਖਤਰਾ, ਅਣਜਾਣੀਆਂ ਅਤੇ ਤੁਹਾਡੇ ਕੋਡ, ਡਿਪੈਂਡੈਂਸੀਜ਼ ਅਤੇ ਫਰੇਮਵਰਕ ਦੀ ਪੁਰਾਣੀ ਵਰਤੋਂ ਵਿਚਕਾਰ ਛੁਪੇ ਨਿਰਭਰਤਾਵਾਂ ਨਾਲ ਚਲਦੇ ਹਨ।
ਇੱਕ ਅੱਪਡੇਟ ਮੁੱਖ ਸਿਸਟਮ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਨਵੇਂ ਫਰੇਮਵਰਕ ਵਰਜਨ 'ਤੇ ਲਿਜਾਣ ਦਾ ਲਕਸ਼ ਰੱਖਦਾ ਹੈ।
ਭਾਵੇਂ ਤੁਸੀਂ “ਸਿਰਫ਼” ਅੱਪਡੇਟ ਕਰ ਰਹੇ ਹੋ, ਪਰ ਤੁਹਾਨੂੰ authentication, routing, state management, build tooling ਅਤੇ observability 'ਤੇ ਵਿਆਪਕ ਲੇਗੇਸੀ ਮੇਨਟੇਨੈਂਸ ਕਰਨੀ ਪੈ ਸਕਦੀ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਫਿਰ ਇੱਕ ਸਥਿਰ ਬੇਜ਼ਲਾਈਨ 'ਤੇ ਆ ਸਕੋ।
ਇੱਕ ਰੀਰਾਈਟ ਰਾਜੀਨਾਤਮਕ ਤੌਰ 'ਤੇ ਸਿਸਟਮ ਦੇ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਿਆਂ ਨੂੰ ਨਵੀਂ, ਸਾਫ਼ ਬੇਜ਼ਲਾਈਨ 'ਤੇ ਦੁਬਾਰਾ ਬਣਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਉਹੀ ਫੀਚਰ ਅਤੇ ਡੇਟਾ ਮਾਡਲ ਰੱਖ ਸਕਦੇ ਹੋ, ਪਰ ਤੁਹਾਨੂੰ ਪੁਰਾਣੇ ਅੰਦਰੂਨੀ ਡਿਜ਼ਾਈਨ ਫੈਸਲਿਆਂ ਨੂੰ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਬਰਕਰਾਰ ਰੱਖਣਾ ਨਹੀਂ ਪੈਂਦਾ।
ਇਹ ਸਾਫਟਵੇਅਰ ਮਾਡਰਨਾਈਜ਼ੇਸ਼ਨ ਦੇ ਕੋਲ ਹੋ ਨਜ਼ਦੀਕ ਹੈ ਕਿਉਂਕਿ ਅਸਲ ਸਵਾਲ ਸੀਮਾ ਨਿਰਧਾਰਣ ਅਤੇ ਨਿਸਚਿਤਤਾ ਬਾਰੇ ਹੁੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਮੇਜਰ ਅਪਗਰੇਡ ਨੂੰ ਛੋਟੇ ਪੈਚ ਵਾਂਗ ਟ੍ਰੀਟ ਕਰੋਗੇ ਤਾਂ ਤੁਸੀਂ ਛੁਪੇ ਹੋਏ ਖ਼ਰਚ ਮਿਸ ਕਰ ਦੋਗੇ: ਡਿਪੈਂਡੈਂਸੀ ਚੇਨ ਟਕਰਾਅ, ਵਧੀ ਹੋਈ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟਿੰਗ ਅਤੇ ਬ੍ਰੇਕਿੰਗ ਚੇਜ਼ਜ਼ ਕਾਰਨ “ਅਚਾਨਕ” ਰੀਫੈਕਟਰਨਗ।
ਹੇਠਾਂ ਅਸੀਂ ਅਸਲ ਖ਼ਰਚ ਚਲਾਉਣ ਵਾਲੇ ਕਾਰਕਾਂ ਨੂੰ ਦੇਖਾਂਗੇ—ਟੈਕਨੀਕੀ ਕਰਜ਼, ਡਿਪੈਂਡੈਂਸੀ ਡੋਮੀਨੋ ਪ੍ਰਭਾਵ, ਟੈਸਟਿੰਗ ਅਤੇ ਰਿਗ੍ਰੈਸ਼ਨ ਖਤਰਾ, ਟੀਮ ਵੈਲੋਸਿਟੀ 'ਤੇ ਪ੍ਰਭਾਵ, ਅਤੇ ਇੱਕ ਵਿਆਵਹਾਰਿਕ ਰਣਨੀਤੀ ਕਿ ਕਦੋਂ ਅੱਪਡੇਟ ਮੁਨਾਸਿਬ ਹੈ ਤੇ ਕਦੋਂ ਰੀਰਾਈਟ ਸਸਤਾ ਤੇ صاف ਰਾਹ ਹੋ ਸਕਦਾ ਹੈ।
ਫਰੇਮਵਰਕ ਵਰਜਨ ਸ਼ੁੱਧ ਤੌਰ 'ਤੇ ਇਸ ਲਈ ਨਹੀਂ ਡਰਿਫਟ ਕਰਦੇ ਕਿ ਟੀਮਾਂ ‘ਪਰਵਾ ਨਹੀਂ ਕਰਦੀਆਂ’। ਉਹ ਇਸ ਲਈ ਡਰਿਫਟ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਅੱਪਡੇਟ ਕੰਮ ਉਹਨਾਂ ਫੀਚਰਾਂ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦਾ ਹੈ ਜੋ ਗਾਹਕਾਂ ਨੂੰ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਅੱਪਡੇਟ ਮੁਲਤਵੀ ਕਰਦੀਆਂ ਹਨ ਕਈ ਪ੍ਰੈਕਟਿਕਲ ਅਤੇ ਜਜ਼ਬਾਤੀ ਕਾਰਨਾਂ ਕਰਕੇ:
ਹਰ ਦੇਰੀ ਆਪਣੇ ਆਪ ਵਿੱਚ ਵਾਜਿਬ ਹੈ। ਸਮਸਿਆ ਉਸ ਤੋਂ ਬਾਅਦ ਆਉਂਦੀ ਹੈ ਜੋ ਹੋਂਦੀ ਹੈ।
ਇੱਕ ਵਰਜਨ ਛੱਡ ਦੇਣਾ ਆਮਤੌਰ 'ਤੇ ਉਹ ਟੂਲਿੰਗ ਅਤੇ ਗਾਈਡੈਂਸ ਵੀ ਛੱਡ ਦਿੰਦਾ ਹੈ ਜੋ ਅਪਗਰੇਡ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ (ਡੀਪ੍ਰੇਕੇਸ਼ਨ ਵਾਰਨਿੰਗ, codemods, ਮਾਈਗ੍ਰੇਸ਼ਨ ਗਾਈਡ)। ਕੁਝ ਚਕਰਾਂ ਦੇ ਬਾਅਦ, ਤੁਸੀਂ ਹੁਣ “ਅਪਗਰੇਡ” ਨਹੀਂ ਕਰ ਰਹੇ—ਤੁਸੀਂ ਕਈ ਆਰਕੀਟੈਕਚਰਕ ਯੁੱਗਾਂ ਨੂੰ ਇਕੱਠੇ ਪਾਰ ਕਰ ਰਹੇ ਹੋ।
ਇਹ ਅੰਤਰ ਹੈ:
ਪੁਰਾਣੇ ਫਰੇਮਵਰਕ ਸਿਰਫ਼ ਕੋਡ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਤੁਹਾਡੇ ਟੀਮ ਦੀ ਚਲਾਉਣ ਦੀ ਯੋਗਤਾ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ:
ਫਰੇਮਵਰਕ ਅੱਪਡੇਟ ਅਕਸਰ “ਫਰੇਮਵਰਕ ਦੇ ਅੰਦਰ” ਹੀ ਨਹੀਂ ਰਹਿੰਦੇ। ਜੋ ਇੱਕ ਵਰਜਨ ਬੰਧਨ ਵਜੋਂ ਲੱਗਦਾ ਹੈ, ਉਹ ਅਕਸਰ ਹਰ ਚੀਜ਼ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਂਉਂਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਬਣਾਉਂਦਾ, ਚਲਾਉਂਦਾ ਅਤੇ ਸ਼ਿਪ ਕਰਵਾਉਂਦਾ ਹੈ।
ਆਧੁਨਿਕ ਫਰੇਮਵਰਕ ਕਈ ਚਲਦੀਆਂ ਹਿੱਸਿਆਂ ਦੇ ਉਪਰ ਹੁੰਦਾ ਹੈ: ਰਨਟਾਈਮ ਵਰਜਨ (Node, Java, .NET), ਬਿਲਡ ਟੂਲ, ਬੰਡਲਰ, ਟੈਸਟ ਰਨਰ, ਲਿੰਟਰ ਅਤੇ CI ਸਕ੍ਰਿਪਟ। ਜਦੋਂ ਫਰੇਮਵਰਕ ਨਵਾਂ ਰਨਟਾਈਮ ਮੰਗਦਾ ਹੈ, ਤੁਸੀਂ ਸ਼ਾਇਦ ਇਹ ਵੀ ਅੱਪਡੇਟ ਕਰਨੇ ਪਾ ਸਕਦੇ ਹੋ:
ਇਹ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ “ਫੀਚਰ” ਨਹੀਂ ਹਨ, ਪਰ ਹਰ ਇੱਕ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮਾਂ ਖਾਧਾ ਕਰਦਾ ਹੈ ਅਤੇ ਅਣਧਿਆਨ ਵਾਲੀਆਂ ਸਰਪ੍ਰਾਈਜ਼ਾਂ ਦੀ ਸੰਭਾਵਨਾ ਵਧਾਉਂਦਾ ਹੈ।
ਭਾਵੇਂ ਤੁਹਾਡਾ ਆਪਣਾ ਕੋਡ ਤਿਆਰ ਹੋਵੇ, ਡਿਪੈਂਡੈਂਸੀਜ਼ ਤੁਹਾਨੂੰ ਰੋਕ ਸਕਦੀਆਂ ਹਨ। ਆਮ ਪੈਟਰਨ:
ਡਿਪੈਂਡੈਂਸੀ ਬਦਲਣਾ ਆਮ ਤੌਰ 'ਤੇ drop-in swap ਨਹੀਂ ਹੁੰਦਾ; ਇਹ ਇੰਟੇਗ੍ਰੇਸ਼ਨ ਪੁਆਇੰਟਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ, ਵਿਹਾਰ ਨੂੰ ਦੁਬਾਰਾ ਵੈਰੀਫਾਈ ਕਰਨਾ ਅਤੇ ਟੀਮ ਲਈ ਨਵੀਆਂ APIs ਦੀ ਦਸਤਾਵੇਜ਼ਿਕਰਨ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ।
ਅੱਪਡੇਟ ਅਕਸਰ ਪੁਰਾਣੀ ਬ੍ਰਾਊਜ਼ਰ ਸਹਾਇਤਾ ਹਟਾਉਂਦੇ ਹਨ, ਪੋਲੀਫਿਲ ਲੋਡ ਕਰਨ ਦਾ ਤਰੀਕਾ ਬਦਲਦੇ ਹਨ, ਜਾਂ ਬੰਡਲਰ ਉਮੀਦਾਂ ਨੂੰ ਬਦਲਦੇ ਹਨ। ਛੋਟੇ ਕਾਨਫਿਗ ਫਰਕ (Babel/TypeScript ਸੈਟਿੰਗ, ਮੋਡੀਊਲ ਰਿਜ਼ੋਲੂਸ਼ਨ, CSS ਟੂਲਿੰਗ, ਅੈਸੈੱਟ ਹੈਂਡਲਿੰਗ) ਨੂੰ ਡਿਬੱਗ ਕਰਨ ਵਿੱਚ ਘੰਟੇ ਲੱਗ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਫੇਲ ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਅਸਪਸ਼ਟ ਬਿਲਡ ਏਰਰਾਂ ਵਜੋਂ ਦਿਖਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਇੱਕ ਕੰਪੈਟਿਬਿਲਿਟੀ ਮੈਟ੍ਰਿਕਸ ਨਾਲ ਸੌਦਬਾਜ਼ੀ ਕਰਦੀਆਂ ਹਨ: ਫਰੇਮਵਰਕ ਵਰਜਨ X ਰਨਟਾਈਮ Y ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ, ਜੋ ਬੰਡਲਰ Z ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ, ਜੋ ਪਲਗਇਨ A ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ, ਜੋ ਲਾਇਬ੍ਰੇਰੀ B ਨਾਲ ਟਕਰਾਉਂਦਾ ਹੈ। ਹਰ ਪਾਬੰਦੀ ਹੋਰ ਤਬਦੀਲੀ ਨੂੰ ਮਜਬੂਰ ਕਰਦੀ ਹੈ, ਅਤੇ ਕੰਮ ਵਧ ਜਾਂਦਾ ਹੈ ਜਦ ਤੱਕ ਪੂਰੀ ਟੂਲਚੇਨ ਸਹਿਮਤ ਨਹੀਂ ਹੋ ਜਾਂਦੀ। ਇੱਥੇ ਹੀ “ਇੱਕ ਛੋਟਾ ਅੱਪਡੇਟ” ਸ਼ਾਂਤੀ ਨਾਲ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।
ਫਰੇਮਵਰਕ ਅੱਪਡੇਟ ਮਹਿੰਗੇ ਹੋ ਜਾਂਦੇ ਹਨ ਜਦ ਉਹ “ਸਿਰਫ਼ ਵਰਜਨ ਬੰਨ੍ਹ” ਨਹੀਂ ਹੁੰਦੇ। ਅਸਲ ਬਜਟ ਖੇਡਣ ਵਾਲੀ ਚੀਜ਼ ਬ੍ਰੇਕਿੰਗ ਚੇਜ਼ਜ਼ ਹਨ: APIs ਹਟਾਉਣਾ ਜਾਂ ਨਾਮ ਬਦਲਣਾ, ਡਿਫਾਲਟ ਬਦਲ ਜਾਣੇ, ਅਤੇ ਵਿਹਾਰ ਅੰਤਰ ਜੋ ਸਿਰਫ਼ ਖਾਸ ਫਲੋਜ਼ 'ਚ ਦਿਖਦੇ ਹਨ।
ਇੱਕ ਨਰਮ routing ਐਡਜ ਕੇਸ ਜੋ ਸਾਲਾਂ ਤੱਕ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ ਉਹੁ ਹੁਣ ਵੱਖ-ਵੱਖ ਸਟੇਟਸ ਕੋਡ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ। ਕਿਸੇ ਕੰਪੋਨੇਟ ਦੀ ਲਾਈਫਸਾਇਕਲ ਮੈਥਡ ਨਵੇਂ ਕ੍ਰਮ ਵਿੱਚ ਫਾਇਰ ਹੋ ਸਕਦੀ ਹੈ। ਅਚਾਨਕ ਅਪਗਰੇਡ ਸਿਰਫ਼ ਡਿਪੈਂਡੈਂਸੀਅਜ਼ ਅੱਪਡੇਟ ਬਾਰੇ ਨਹੀਂ ਰਹਿੰਦਾ—ਇਹ ਸਹੀਤਾ ਮੁੜ-ਪੁਸ਼ਟੀਕਰਨ ਦਾ ਕੰਮ ਬਣ ਜਾਂਦਾ ਹੈ।
ਕੁਝ ਬ੍ਰੇਕਿੰਗ ਚੇਜ਼ਜ਼ ਸਪੱਸ਼ਟ ਹੁੰਦੇ ਹਨ (ਤੁਹਾਡਾ ਬਿਲਡ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ)। ਹੋਰ ਨਰਮ ਹੁੰਦੇ ਹਨ: ਜਿਆਦਾ ਸਖ਼ਤ ਵੈਲਿਡੇਸ਼ਨ, ਵੱਖ-ਵੱਖ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਫਾਰਮੈਟ, ਨਵੀਂ ਸੁਰੱਖਿਆ ਡਿਫਾਲਟ, ਜਾਂ ਟਾਈਮਿੰਗ ਬਦਲਾਅ ਜੋ ਰੇਸ ਕੰਡੀਸ਼ਨ ਬਣਾਉਂਦੇ ਹਨ। ਇਹ ਸਮਾਂ ਖਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਦੇਰ ਨਾਲ ਲੱਭਦੇ ਹੋ—ਅਕਸਰ ਅੱਧੇ ਟੈਸਟਿੰਗ ਦੇ ਬਾਅਦ—ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਕਈ ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਸਰਵਿਸز ਵਿਚੋਂ ਪਿੱਛੇ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
ਅਪਗਰੇਡ ਅਕਸਰ ਛੋਟੀ ਰੀਫੈਕਟਰਿੰਗਾਂ ਦੀ ਲੜੀ ਮੰਗਦੇ ਹਨ ਜੋ ਹਰ ਜਗ੍ਹਾ ਫੈਲੀਆਂ ਹੁੰਦੀਆਂ ਹਨ: ਇੰਪੋਰਟ ਪਾਥ ਬਦਲਣਾ, ਮੈਥਡ ਸਿਗਨੇਚਰ ਅਪਡੇਟ ਕਰਨਾ, ਡੀਪ੍ਰੇਕੇਟਿਡ ਹੈਲਪਰ ਬਦਲਣਾ, ਜਾਂ ਦਰਜਨਾਂ (ਯਾ ਸੈਂਕੜਿਆਂ) ਫਾਇਲਾਂ ਵਿੱਚ ਕੁਝ ਲਾਈਨਾਂ ਦੁਬਾਰਾ ਲਿਖਣੀਆਂ। ਵੱਖ-ਵੱਖ ਤੌਰ 'ਤੇ ਹਰ ਸੋਧ ਛੋਟੀ ਦਿਸਦੀ ਹੈ। ਸਮੂਹਿਕ ਤੌਰ 'ਤੇ, ਇਹ ਇੱਕ ਲੰਮਾ, ਬਾਧਾ-ਚਲਾਇਆ ਪ੍ਰੋਜੈਕਟ ਬਣ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ ਇੰਜੀਨੀਅਰ ਕੋਡਬੇਸ ਵਿੱਚ ਰਸਤਾ ਲੱਭਣ ਵਿੱਚ ਜ਼ਿਆਦਾ ਸਮਾਂ ਬਿਤਾਉਂਦੇ ਹਨ ਨਿਕਿ ਮੁੱਖ ਤਰੱਕੀ।
ਡੀਪ੍ਰੇਕੇਸ਼ਨਸ ਟੀਮਾਂ ਨੂੰ ਨਵੇਂ ਪੈਟਰਨ ਅਪਣਾਉਣ ਲਈ ਧੱਕ ਸਕਦੀਆਂ ਹਨ ਬਜਾਏ ਸਿੱਧਾ ਬਦਲਾਅ ਦੇ। ਫਰੇਮਵਰਕ ਸ਼ਾਇਦ ਨਵੇਂ ਰਾਹ (routing, state management, dependency injection, ਜਾਂ data fetching) ਨੂੰ ਦਬਾਏ।
ਇਹ ਰੀਫੈਕਟਰਨਗ ਨਹੀਂ—ਇਹ ਛੁਪੇ ਹੋਏ ਰੂਪ ਵਿੱਚ ਰੀ-ਆਰਕੀਟੈਕਚਰ ਹੈ, ਕਿਉਂਕਿ ਪੁਰਾਣੇ ਰਿਵਾਜ ਹੁਣ ਫਰੇਮਵਰਕ ਦੇ “ਖੁਸ਼ੀ ਦਾ ਰਾਹ” ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ।
ਜੇ ਤੁਹਾਡੇ ਐਪ ਵਿੱਚ ਅੰਦਰੂਨੀ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਹਨ—ਕਸਟਮ UI ਕੰਪੋਨੈਂਟ, HTTP ਲਈ ਯੂਟਿਲਿਟੀ ਰੈਪਰ, auth, forms ਜਾਂ state—ਤਾਂ ਫਰੇਮਵਰਕ ਬਦਲਾਅ ਉਪਰਿਤ ਰਹਿਤ ਪ੍ਰਭਾਵ ਪਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਸਿਰਫ਼ ਫਰੇਮਵਰਕ ਨੂੰ ਅਪਡੇਟ ਨਹੀਂ ਕਰਦੇ; ਤੁਸੀਂ ਉਸ ਸਾਰੇ ਢਾਂਚੇ ਨੂੰ ਅਪਡੇਟ ਕਰਦੇ ਹੋ ਜੋ ਉਸ 'ਤੇ ਬਣਿਆ ਹੈ, ਫਿਰ ਹਰ ਕੰਜ਼ਿਊਮਰ ਨੂੰ ਦੁਬਾਰਾ ਵੈਰੀਫਾਈ ਕਰਦੇ ਹੋ।
ਸ਼ੇਅਰਡ ਲਾਇਬ੍ਰੇਰੀਜ਼ ਜੇਕਰ ਕਈ ਐਪਾਂ 'ਚ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਇਹ ਕੰਮ ਹੋਰ ਵਧ ਜਾਂਦਾ ਹੈ, ਇੱਕ ਉਪਗਰੇਡ ਨੂੰ ਕਈ ਕੂਆਰਡੀਨੇਟਿਡ ਮਾਈਗਰੇਸ਼ਨਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਫਰੇਮਵਰਕ ਅੱਪਡੇਟ ਅਕਸਰ ਇਸ ਲਈ ਫੇਲ ਹੁੰਦੇ ਹਨ ਕਿ ਕੋਡ “ਕੰਪਾਇਲ ਨਹੀਂ ਹੁੰਦਾ।” ਅਕਸਰ ਫੇਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਕੋਈ ਨਰਮ ਗਲਤੀਆਂ ਪ੍ਰੋਡਕਸ਼ਨ 'ਚ ਟੁੱਟਦੀਆਂ ਹਨ: ਇੱਕ ਵੈਲਿਡੇਸ਼ਨ ਰੂਟਿਨ ਰੁਕ ਜਾਂਦੀ ਹੈ, ਲੋਡਿੰਗ ਸਟੇਟ ਕਦੇ ਕਲੀਅਰ ਨਹੀਂ ਹੁੰਦਾ, ਜਾਂ permissions ਚੇਕ ਬਿਹੇਵਿਅਰ ਬਦਿ ਜਾਂਦਾ ਹੈ।
ਟੈਸਟਿੰਗ ਸੁਰੱਖਿਆ ਜਾਲ ਹੈ—ਅਤੇ ਇਹੀ ਓਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਅਪਗਰੇਡ ਬਜਟ ਚੁੱਪਚਾਪ ਫੈਲਦਾ ਹੈ।
ਟੀਮਾਂ ਅਕਸਰ ਦੇਰ ਨਾਲ ਪਤਾ ਲਾਉਂਦੀਆਂ ਹਨ ਕਿ ਉਹਨਾਂ ਦੀ ਆਟੋਮੇਟਡ ਕਵਰੇਜ ਪਤਲੀ, ਪ੍ਰਾਣੇ ਹੋ ਚੂਕੀ ਜਾਂ ਗਲਤ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਹੈ। ਜੇ ਵੱਡੀ ਭਰੋਸਾ-ਯੋਗਤਾ “ਕਲਿੱਕ ਕਰਕੇ ਵੇਖੋ” 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ ਹਰ ਫਰੇਮਵਰਕ ਬਦਲਾਅ ਇੱਕ ਉੱਚ-ਚਿੰਤਾ ਵਾਲਾ ਅਨੁਮਾਨ ਖੇਡ ਬਣ ਜਾਂਦਾ ਹੈ।
ਜਦ ਆਟੋਮੇਟਡ ਟੈਸਟ ਘੱਟ ਹੁੰਦੇ ਹਨ, ਅੱਪਡੇਟ ਦਾ ਖਤਰਾ ਮਨੁੱਖਾਂ ਤੇ ਚਲਾ ਜਾਂਦਾ ਹੈ: ਹੋਰ ਮੈਨੁਅਲ QA ਸਮਾਂ, ਹੋਰ ਬੱਗ ਟ੍ਰਾਇਏਜ, ਸਟੇਕਹੋਲਡਰ ਚਿੰਤਾ ਅਤੇ ਟੀਮ ਵੱਖ-ਵੱਖ ਰਿਗ੍ਰੈਸ਼ਨ ਖੋਜਦੇ ਹੋਏ ਦੇਰੀ।
ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਕੋਲ ਟੈਸਟ ਸਨ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਅੱਪਗਰੇਡ ਦੌਰਾਨ ਵੱਡੀ ਟੈਸਟਿੰਗ ਰੀਰਾਈਟ ਦੀ ਲੋੜ ਪੈ ਸਕਦੀ ਹੈ। ਆਮ ਕੰਮ ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ:
ਇਹ ਅਸਲ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮਾਂ ਹੈ, ਅਤੇ ਇਹ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਫੀਚਰ ਡਿਲਿਵਰੀ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦਾ ਹੈ।
ਘੱਟ ਆਟੋਮੈਟਿਕ ਕਵਰੇਜ ਮੈਨੁਅਲ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟਿੰਗ ਵਧਾਉਂਦੀ ਹੈ: ਡਿਵਾਈਸਾਂ, ਭੂਮਿਕਾਵਾਂ ਅਤੇ ਵਰਕਫਲੋਜ਼ 'ਤੇ ਦੁਹਰਾਈ ਜਾਂਦੀ ਚੈੱਕਲਿਸਟ। QA ਨੂੰ “ਬਦਲਾਅ ਨਹੀਂ ਹੋਏ” ਫੀਚਰਾਂ ਨੂੰ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰਨ ਲਈ ਹੋਰ ਸਮਾਂ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਤਪਾਦ ਟੀਮਾਂ ਨੂੰ ਉਮੀਦਵਾਰ ਵਿਹਾਰ ਨੂੰ ਵੱਖ-ਵੱਖ ਤੌਰ 'ਤੇ ਸਪਸ਼ਟ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਜਦ ਅਪਗਰੇਡ ਡਿਫਾਲਟ ਬਦਲਦਾ ਹੈ।
ਇੱਥੇ ਕੋਆਰਡੀਨੇਸ਼ਨ ਓਹ ਵੀਤਰ-ਖ਼ਰਚ ਹੁੰਦੀ ਹੈ: ਰਿਲੀਜ਼ ਵਿੰਡੋ ਸਹਿਮਤ ਕਰਨੀ, ਸਟੇਕਹੋਲਡਰਾਂ ਨੂੰ ਖਤਰੇ ਦੀ ਜਾਣਕਾਰੀ ਦੇਨੀ, ਐਕਸੈਪਟੈਂਸ ਮਾਪਦੰਡ ਇਕੱਠੇ ਕਰਨੇ, ਕੀ ਮੁੜ-ਵੈਰੀਫਾਈ ਕਰਨਾ ਹੈ ਉਸਦਾ ਟਰੈਕ ਰੱਖਣਾ, ਅਤੇ UAT ਦੀ ਸ਼ੈਡਿਊਲਿੰਗ। ਜਦੋਂ ਟੈਸਟਿੰਗ ਭਰੋਸਾ ਘੱਟ ਹੁੰਦਾ ਹੈ, ਅੱਪਡੇਟ ਸਲੋ ਹੋ ਜਾਂਦੇ ਹਨ—ਇਸ ਲਈ ਨਹੀਂ ਕਿ ਕੋਡ ਮੁਸ਼ਕਲ ਹੈ, ਪਰ ਇਸ ਲਈ ਕਿ ਇਹ ਸਾਬਤ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ ਕਿ ਇਹ ਅਧੀਕ ਕੰਮ ਕਰਦਾ ਹੈ।
ਟੈਕਨੀਕੀ ਕਰਜ਼ ਉਹ ਹੁੰਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਲਈ ਇੱਕ شارਟਕਟ ਲੈਂਦੇ ਹੋ—ਫਿਰ ਬਾਦ ਵਿੱਚ “ਸੁਦ” ਦੇ ਰੂਪ ਵਿੱਚ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ। شارਟਕਟ ਇੱਕ ਤੁਰੰਤ ਹੱਲ, ਇੱਕ ਗੁੰਝਲਦਾਰ ਟੈਸਟ ਘਾਟ, ਇੱਕ ਝੱਲੇ ਟਿੱਪਣੀ ਦੀ ਥਾਂ ਦਸਤਾਵੇਜ਼, ਜਾਂ ਕਾਪੀ-ਪੇਸਟ ਫਿਕਸ ਹੋ ਸਕਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ “ਅਗਲੇ ਸਪ੍ਰਿੰਟ” 'ਚ ਸਾਫ਼ ਕਰਨ ਦਾ ਸੋਚਦੇ ਹੋ। ਇਹ ਤਦ ਤੱਕ ਚੱਲਦਾ ਹੈ ਜਦ ਤੱਕ ਤੁਹਾਨੂੰ ਕਿਸੇ ਚੀਜ਼ ਹੇਠਾਂ ਬਦਲ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ।
ਫਰੇਮਵਰਕ ਅੱਪਡੇਟ ਉਨ੍ਹਾਂ ਕੋਡ ਹਿੱਸਿਆਂ ’ਤੇ ਰੋਸ਼ਨੀ ਪਾਂਦੇ ਹਨ ਜੋ ਐਕਸੀਡੈਂਟਲ ਵਿਹਾਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਸਨ। ਸ਼ਾਇਦ ਪੁਰਾਣਾ ਵਰਜ਼ਨ ਇੱਕ ਵਿਅੰਗਤ ਲਾਈਫਸਾਇਕਲ ਟਾਈਮਿੰਗ, ਢਿੱਲਾ-ਟਾਈਪਡ ਮੁੱਲ, ਜਾਂ CSS ਨਿਯਮ ਨੂੰ ਬਰਦਾਸ਼ਤ ਕਰਦਾ ਰਿਹਾ। ਜਦ ਫਰੇਮਵਰਕ ਨਿਯਮ ਕਸਦਾ ਹੈ, ਡਿਫਾਲਟ ਬਦਲ ਜਾਂਦੇ ਹਨ, ਜਾਂ ਡੀਪ੍ਰੇਕੇਟਿਡ APIs ਹਟਦੇ ਹਨ, ਉਹ ਛੁਪੇ ਧਾਰਣਾਵਾਂ ਟੁੱਟ ਜਾਂਦੀਆਂ ਹਨ।
ਅੱਪਡੇਟ ਤੁਹਾਨੂੰ ਉਹਨਾਂ “ਹੈਕਸ” ਤੇ ਵਾਪਸ ਭੁਗਤਾਨ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦੇ ਹਨ ਜੋ ਕਦੇ ਕਦੇ ਸਥਾਈ ਮਨਿਆ ਨਹੀਂ ਗਏ: monkey patches, ਕਸਟਮ ਫੋਰਕ, ਕੰਪੋਨੈਂਟ ਫ੍ਰੇਮਵਰਕ ਵਿਚ ਸੀਧਾ DOM ਐਕਸੈਸ, ਜਾਂ ਹੱਥ-ਤੋੜੀ auth ਫਲੋ ਜੋ ਨਵੇਂ ਸੁਰੱਖਿਆ ਮਾਡਲ ਨੂੰ ਅਣਡਿੱਠਾ ਕਰਦੀ ਹੈ।
ਜਦ ਤੁਸੀਂ ਅੱਪਡੇਟ ਕਰਦੇ ਹੋ, ਲਕਸ਼ ਅਕਸਰ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਹਰ ਕੁਝ ਵਾਹੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰੇ—ਪਰ ਫਰੇਮਵਰਕ ਆਪਣੇ ਨਿਯਮ ਬਦਲ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਤੁਹਾਨੂੰ ਬਚਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਵੀ ਕਰਨੀ ਪੈਂਦੀ ਹੈ: ਹਰ ਇੱਕ ਕੋਨਾਂ ਦਾ ਵਿਹਾਰ ਉਹੀ ਹੋਵੇ, ਸਮੇਤ ਉਹ ਵਿਹਾਰ ਜੋ ਹੁਣ ਤੱਕ ਕਿਸੇ ਨੇ ਸੁਪਸ਼ਟ ਨਹੀਂ ਕੀਤਾ।
ਕਈ ਵਾਰੀ ਰੀਰਾਈਟ ਸੌਖਾ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇਰਾਦੇ ਨੂੰ ਮੁੜ-ਇੰਪਲੀਮੈਂਟ ਕਰ ਰਹੇ ਹੋ, ਨਾ ਕਿ ਹਰ ਇਤਿਹਾਸਕ ਅਣਜਾਣ ਗਲਤੀ ਦੀ ਰੱਖਿਆ।
ਅੱਪਡੇਟ ਸਿਰਫ਼ ਡਿਪੈਂਡੈਂਸੀ ਬਦਲਦੇ ਨਹੀਂ—ਉਹ ਤੁਹਾਡੇ ਪਿਛਲੇ ਫੈਸਲਿਆਂ ਦੀ ਅੱਜ ਕੀਮਤ ਬਦਲ ਦਿੰਦੇ ਹਨ।
ਇੱਕ ਲੰਬਾ ਚੱਲਣ ਵਾਲਾ ਫਰੇਮਵਰਕ ਅੱਪਡੇਟ ਅਕਸਰ ਇੱਕ ਇਕੱਲਾ ਪ੍ਰੋਜੈਕਟ ਵਾਂਗ ਨਹੀਂ ਲੱਗਦਾ। ਇਹ ਇੱਕ ਸਥਾਈ ਪਿਛੋਕੜ ਟਾਸਕ ਬਣ ਜਾਂਦਾ ਹੈ ਜੋ ਉਤਪਾਦ ਕੰਮ ਤੋਂ ਧਿਆਨ ਚੁਕਾਉਂਦਾ ਰਹਿੰਦਾ ਹੈ। ਜੇਕਰ ਕੁੱਲ ਇੰਜੀਨੀਅਰਿੰਗ ਘੰਟੇ ਕੰਮ ਨਜ਼ਦੀਕ ਤੌਰ 'ਤੇ “ਠੀਕ” ਲੱਗਦੇ ਹਨ, ਅਸਲ ਖ਼ਰਚ ਵੈਲੋਸਿਟੀ ਘਟਣ ਵਜੋਂ ਦਿਖਦਾ ਹੈ: ਕੰਮ ਸ਼ਿਪ ਹੋਣ ਘੱਟ, ਬੱਗ ਤੁਰੰਤ ਠੀਕ ਕਰਨ ਵਿੱਚ ਦੇਰੀ, ਅਤੇ ਜ਼ਿਆਦਾ context-switching।
ਟੀਮਾਂ ਅਕਸਰ ਖਤਰਾ ਘਟਾਉਣ ਲਈ ਕ੍ਰਮਬੱਧ ਅੱਪਡੇਟ ਕਰਦੀਆਂ ਹਨ—ਸਿਧਾ ਵਿਚਾਰ ਚੰਗਾ ਹੈ ਪਰ ਅਮਲ ਵਿੱਚ ਦੁੱਖਦਾਈ। ਤੁਸੀਂ ਇੱਕ ਐਸਾ ਕੋਡਬੇਸ ਮਿਲਦਾ ਹੈ ਜਿੱਥੇ ਕੁਝ ਹਿੱਸੇ ਨਵੇਂ ਫਰੇਮਵਰਕ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ ਅਤੇ ਹੋਰ ਪੁਰਾਣੇ ਪੈਟਰਨ 'ਤੇ ਟਿਕੇ ਰਹਿੰਦੇ ਹਨ।
ਉਹ ਮਿਲੀ-ਜੁਲੀ ਹਾਲਤ ਹਰ ਕਿਸੇ ਨੂੰ ਮੰਦ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਇੰਜੀਨੀਅਰ ਇੱਕ ਸਥਿਰ ਰੀਤਨੀਤੀ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਆਮ ਲਛਣ ਹੈ “ਉਹੋ ਹੀ ਕੰਮ ਕਰਨ ਦੇ ਦੋ ਤਰੀਕੇ।” ਉਦਾਹਰਨ ਲਈ, ਤੁਹਾਡੇ ਕੋਲ legacy routing ਅਤੇ ਨਵੇਂ router ਦੋਹਾਂ ਹੋ ਸਕਦੇ ਹਨ, ਪੁਰਾਣਾ state management ਨਵੇਂ ਦੇ ਨਾਲ ਮਿਲਿਆ ਹੋਇਆ, ਜਾਂ ਦੋ ਟੈਸਟਿੰਗ ਸੈਟਅੱਪ ਇਕੱਠੇ।
ਹਰ ਬਦਲਾਅ ਇੱਕ ਛੋਟਾ ਫੈਸਲਾ ਬਣ ਜਾਂਦਾ ਹੈ:
ਇਹ ਸਵਾਲ ਹਰ ਟਾਸਕ ਵਿੱਚ ਮਿੰਟਾਂ ਜੋੜਦੇ ਹਨ, ਅਤੇ ਮਿੰਟ ਦਿਨਾਂ ਵਿੱਚ ਵੱਧ ਜਾਂਦੇ ਹਨ।
ਮਿਲੇ-ਜੁਲੇ ਪੈਟਰਨ ਕੋਡ ਰਿਵਿਊ ਨੂੰ ਮਹਿੰਗਾ ਬਣਾ ਦਿੰਦੇ ਹਨ। ਰਿਵਿਊਅਰਾਂ ਨੂੰ ਸਹੀਤਾ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੋਹਾਂ ਦੀ ਜਾਂਚ ਕਰਨੀ ਪੈਂਦੀ ਹੈ: “ਕੀ ਇਹ ਨਵਾਂ ਕੋਡ ਅੱਗੇ ਵਧ ਰਹਾ ਹੈ, ਜਾਂ ਪੁਰਾਣੇ ਅੰਦਾਜ਼ ਨੂੰ ਹੋਰ ਗਹਿਰਾ ਕਰ ਰਿਹਾ ਹੈ?” ਗੱਲ-ਬਾਤ ਬੜ੍ਹ ਜਾਂਦੀ ਹੈ, ਨੀਤੀ ਦੀਆਂ ਚਰਚਾਵਾਂ ਵੱਧਦੀਆਂ ਹਨ, ਅਤੇ ਮਨਜ਼ੂਰੀਆਂ ਸਲੋ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
ਨਵੇਂ ਮੈਂਬਰਾਂ ਦੀ ਔਂਬੋਰਡਿੰਗ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦੀ ਹੈ—ਉਹ ਇੱਕ ਸਾਫ਼ ‘ਫਰੇਮਵਰਕ ਤਰੀਕਾ’ ਨਹੀਂ ਸਿੱਖ ਸਕਦੇ ਕਿਉਂਕਿ ਇੱਕ ਨਹੀਂ ਹੈ—ਪੁਰਾਣਾ ਰਾਹ, ਨਵਾਂ ਰਾਹ, ਅਤੇ ਤਬਦੀਲੀ ਨਿਯਮ ਇਕੱਠੇ ਹਨ। ਅੰਦਰੂਨੀ ਡੌਕਸ ਨੂੰ ਲਗਾਤਾਰ ਅਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਅਕਸਰ ਉਨ੍ਹਾਂ ਦਾ ਸਟੇਟ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦਰਮਿਆਨ ਬਾਹਰ ਹੋ ਜਾਂਦਾ ਹੈ।
ਫਰੇਮਵਰਕ ਅੱਪਡੇਟ ਅਕਸਰ ਦੈਨੀਕ ਡਿਵੈਲਪਰ ਵਰਕਫਲੋ ਨੂੰ ਬਦਲ ਦਿੰਦੇ ਹਨ: ਨਵਾਂ ਬਿਲਡ ਟੂਲ, ਵੱਖ-ਵੱਖ ਲਿੰਟ ਨਿਯਮ, ਅਪਡੇਟ CI ਸਟੈਪ, ਲੋڪل ਸੈਟਅੱਪ ਬਦਲਣਾ, ਨਵੀਆਂ ਡਿਬੱਗਿੰਗ ਰੀਤੀ-ਰਿਵਾਜ। ਹਰ ਇੱਕ ਬਦਲਾਅ ਛੋਟਾ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਕੱਠੇ ਉਹ ਇੱਕ ਸਥਿਰ ਰੁਕਾਵਟ ਦਾ ਸ੍ਰੋਤ ਬਣ ਜਾਂਦੇ ਹਨ।
“ਅਪਗਰੇਡ ਨੂੰ ਕਿੰਨੀ ਇੰਜੀਨੀਅਰ-ਹਫਤੇ ਲੱਗਣਗੀਆਂ?” ਪੁੱਛਣ ਦੀ ਬਜਾਏ, ਮੌਕਾ ਖ਼ਰਚ ਮਾਪੋ: ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਪ੍ਰਿੰਟ ਵਿੱਚ 10 ਪੋਂਟ ਭੇਜਦੀ ਹੈ ਅਤੇ ਅੱਪਡੇਟ ਕਾਲ ਵਿੱਚ ਉਹ 6 ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਤਕਰੀਬਨ 40% ਦਾ ‘ਟੈਕਸ’ ਦੇ ਰਹੇ ਹੋ। ਇਹ ਟੈਕਸ ਅਕਸਰ ਦਿਖਣ ਵਾਲੇ ਅਪਗਰੇਡ ਟਿਕਟਾਂ ਨਾਲੋਂ ਵੱਡਾ ਹੁੰਦਾ ਹੈ।
ਫਰੇਮਵਰਕ ਅੱਪਡੇਟ ਅਕਸਰ “ਛੋਟਾ” ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਸਕੋਪ ਦੋਹਾਂ ਲਈ ਮੁਸ਼ਕਲ ਹੈ। ਤੁਸੀਂ ਮੌਜੂਦਾ ਸਿਸਟਮ ਨੂੰ ਨਵੀਆਂ ਨਿਯਮਾਂ ਹੇਠ ਬਣਾਏ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ—ਦੌਰਾਨ ਤੁਸੀਂ ਸਾਲਾਂ ਦੇ ਸ਼ਾਰਟਕਟ, ਹੈਕਸ ਅਤੇ ਅਣਦਸਤਾਵੇਜ਼ ਵਿਵਹਾਰਾਂ ਨੂੰ ਖੋਜਦੇ ਹੋ।
ਇੱਕ ਰੀਰਾਈਟ ਸਸਤਾ ਹੋ ਸਕਦਾ ਹੈ ਜਦ ਇਹ ਸਪਸ਼ਟ ਲਕਸ਼ਾਂ ਅਤੇ ਜਾਣੇ-ਪਛਾਣੇ ਨਤੀਜਿਆਂ ਦੇ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੋਵੇ। “ਹਰ ਚੀਜ਼ ਨੂੰ ਫਿਰ ਠੀਕ ਕਰੋ” ਦੀ ਬਜਾਏ, ਸਕੋਪ ਹੁੰਦਾ ਹੈ: ਇਹ ਯੂਜ਼ਰ ਜਰਨੀ ਸਮਰਥਨ ਕਰਨੇ, ਇਹ ਪ੍ਰਦਰਸ਼ਨ ਟਾਰਗਟ ਮਿਲਾਉਣੇ, ਇਹ ਸਿਸਟਮਾਂ ਨਾਲ ਇੰਟੇਗ੍ਰੇਟ ਕਰਨੇ, ਅਤੇ ਇਹ ਲੇਗੇਸੀ ਏਂਡਪੌਇੰਟ ਰਿਟਾਇਰ ਕਰਨੇ।
ਇਹ ਸਪਸ਼ਟਤਾ ਯੋਜਨਾ ਬਣਾਉਣ, ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਅਤੇ ਟ੍ਰੇਡ-ਆਫ਼ ਕਰਨਾ ਬਹੁਤ ਹੀ ਵਾਰਤਨਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।
ਰੀਰਾਈਟ ਨਾਲ, ਤੁਸੀਂ ਹਰ ਇਤਿਹਾਸਿਕ ਕੁਂਚਲ ਨੂੰ ਬਚਾਉਣ ਲਈ ਬੰਧੇ ਨਹੀਂ ਹੁੰਦੇ। ਟੀਮ ਇਹ ਫੈਸਲਾ ਕਰ ਸਕਦੀ ਹੈ ਕਿ ਆਜ ਉਤਪਾਦ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਫਿਰ ਉਸੇ ਨੂੰ ਨਿਕਾਰਾ।
ਇਸ ਨਾਲ ਅਸਲ ਵਿੱਚ ਬਚਤ ਹੁੰਦੀ ਹੈ:
ਇੱਕ ਸਾਢਾ ਖ਼ਰਚ ਘਟਾਉਣ ਵਾਲੀ ਰਣਨੀਤੀ ਪੈਰਾ-ਰੇਖਾ ਨਾਲ ਚਲਾਉਣਾ ਹੈ: ਮੌਜੂਦਾ ਸਿਸਟਮ ਨੂੰ ਸਥਿਰ ਰੱਖਦਿਆਂ ਨਵੀਂ ਰੀਪਲੇਸਮੈਂਟ ਨੂੰ ਪਿੱਛੇ-ਹਾਲਤ ਵਿੱਚ ਬਣਾਓ।
ਅਮਲੀ ਤੌਰ 'ਤੇ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਨਵੇਂ ਐਪ ਨੂੰ ਟੁਕੜਿਆਂ ਵਿੱਚ ਡਿਲਿਵਰ ਕੀਤਾ ਜਾਵੇ—ਇੱਕ ਫੀਚਰ ਜਾਂ ਵਰਕਫਲੋ ਇੱਕ ਵਾਰੀ ਵਿੱਚ—ਅਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਧੀਰੇ-ਧੀਰੇ ਰਾਉਟ ਕੀਤਾ ਜਾਵੇ (ਯੂਜ਼ਰ ਗਰੁੱਪ, ਏਂਡਪੌਇੰਟ, ਜਾਂ ਪਹਿਲਾਂ ਇੰਟਰਨਲ ਸਟਾਫ ਫਾਰਮ)। ਕਾਰੋਬਾਰ ਚਲਦਾ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਨੂੰ ਇੱਕ ਸੁਰੱਖਿਅਤ ਰੋਲਆਉਟ ਰਾਹ ਮਿਲਦਾ ਹੈ।
ਰੀਰਾਈਟ ਮੁਫ਼ਤ ਕੁਝ ਨਹੀਂ। ਤੁਸੀਂ ਜਟਿਲਤਾ ਘਟਾਓਣਾ ਘੱਟ ਅੰਦਾਜ਼ ਕਰ ਸਕਦੇ ਹੋ, ਕੋਇ ਐਜ ਕੇਸ ਮਿਸ ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ ਪੁਰਾਣੇ ਬੱਗਾਂ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦਾ ਖਤਰਾ ਲੈ ਸਕਦੇ ਹੋ।
ਫਰਕ ਇਹ ਹੈ ਕਿ ਰੀਰਾਈਟ ਰਿਸਕ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾਂ ਅਤੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਸਾਹਮਣੇ ਆਉਂਦੇ ਹਨ: ਗੁੰਮਸ਼ੁਦਾ ਲੋੜਾਂ ਗੁੰਮਸ਼ੁਦਾ ਫੀਚਰ ਵਜੋਂ, ਇੰਟੇਗ੍ਰੇਸ਼ਨ ਗੈਪ ਨਾਪਸੰਦ ਠਹਿਰਦੇ ਹਨ। ਇਹ ਪਾਰਦਰਸ਼ਤਾ ਖਤਰੇ ਨੂੰ ਮਨਜ਼ੂਰਨ ਢੰਗ ਨਾਲ ਪ੍ਰਬੰਧਨ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ—ਬਦਲਾਅ ਬਾਅਦ ਜਦੋਂ ਰਹੱਸਮਈ ਅਪਗਰੇਡ ਰੀਗ੍ਰੈਸ਼ਨ ਲਈ ਭੁਗਤਾਨ ਨਹੀਂ ਕਰਨਾ ਪੈਂਦਾ।
ਚਰਚਾ ਰੋਕਣ ਦਾ ਤੇਜ਼ ਰਸਤਾ ਕੰਮ ਨੂੰ ਸਕੋਰ ਕਰਨਾ ਹੈ। ਤੁਸੀਂ “ਪੁਰਾਣਾ ਵਿ. ਨਵਾਂ” ਨਹੀਂ ਚੁਣ ਰਹੇ—ਤੁਸੀਂ ਉਸ ਵਿਕਲਪ ਨੂੰ ਚੁਣ ਰਹੇ ਜੋ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਭੇਜਣ ਲਈ ਸਭ ਤੋਂ ਸਪਸ਼ਟ ਰਾਹ ਦਿੰਦਾ ਹੈ।
ਅਪਡੇਟ ਅਕਸਰ ਜਿੱਤਦਾ ਹੈ ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਚੰਗੇ ਟੈਸਟ, ਛੋਟਾ ਵਰਜਨ ਗੈਪ, ਅਤੇ ਸਾਫ਼ ਬਾਉਂਡਰੀਜ਼ ਹਨ ਜਿਹੜੀਆਂ ਤੁਹਾਨੂੰ ਟੁਕੜਿਆਂ 'ਚ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀਆਂ ਹਨ। ਇਹ ਇੱਕ ਮਜ਼ਬੂਤ ਚੋਣ ਹੁੰਦੀ ਹੈ ਜਦ ਡਿਪੈਂਡੈਂਸੀਜ਼ ਸਿਹਤਮੰਦ ਹਨ ਅਤੇ ਟੀਮ migration ਦੇ ਨਾਲ ਨਾਲ ਫੀਚਰ ਵੀ ਡਿਲਿਵਰ ਕਰ ਸਕਦੀ ਹੈ।
ਰੀਰਾਈਟ ਅਕਸਰ ਸਸਤਾ ਪੈਂਦਾ ਹੈ ਜਦ:
ਇਹਨਾਂ ਹਾਲਤਾਂ 'ਚ “ਸਭ ਕੁਝ ਬਚਾਉ” ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਮਹੀਨਿਆਂ ਦਾ ਡਿਟੈਕਟਿਵ ਕੰਮ ਬਣ ਸਕਦੀ ਹੈ।
ਬਿਨਾਂ ਕਿਸੇ ਯੋਜਨਾ ਨੂੰ ਲਾਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, 1–2 ਹਫ਼ਤੇ ਦੀ ਡਿਸਕਵਰੀ ਕਰੋ: ਇੱਕ ਪ੍ਰਤੀਨਿਧੀ ਫੀਚਰ ਅੱਪਡੇਟ ਕਰੋ, ਡਿਪੈਂਡੈਂਸੀਜ਼ ਦੀ ਇਨਵੈਂਟਰੀ ਕਰੋ, ਅਤੇ ਸਬੂਤ ਦੇ ਨਾਲ ਕਮ ਨੰਬਰ ਦਾ ਅੰਦਾਜ਼ਾ ਲਵੋ। ਮਕਸਦ ਪੂਰਨਤਾ ਨਹੀਂ—ਅਣਜਾਣੀਆਂ ਨੂੰ ਘੱਟ ਕਰਨਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਇੱਕ ਇਸਤਰੀਯੋਗ ਪਹੁੰਚ ਚੁਣ ਸਕੋ।
ਵੱਡੇ ਅੱਪਡੇਟ ਖਤਰਨਾਕ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਅਣਜਾਣੀਆਂ ਇਕੱਠੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ: ਅਣਗਾਹ ਡਿਪੈਂਡੈਂਸੀ ਟਕਰਾਅ, ਅਸਪਸ਼ਟ ਰੀਫੈਕਟਰਨਗ ਸਕੋਪ, ਅਤੇ ਟੈਸਟਿੰਗ ਮਹਿਨਤ ਜੋ ਬਾਅਦ ਵਿੱਚ ਹੀ ਸਾਹਮਣੇ ਆਉਂਦੀ ਹੈ। ਤੁਸੀਂ ਇਸ ਅਣਜਾਣੇ ਨੂੰ ਘੱਟ ਕਰ ਸਕਦੇ ਹੋ ਜੇ ਤੁਸੀਂ ਅੱਪਡੇਟ ਨੂੰ ਉਤਪਾਦ ਕੰਮ ਵਾਂਗ ਤਰੀਕਾਬੱਧ ਕਰੋ—ਮਾਪਣਯੋਗ ਟੁਕੜੇ, ਜਲਦੀ ਵੈਰੀਫਿਕੇਸ਼ਨ, ਅਤੇ ਨਿਯੰਤਰਿਤ ਰਿਲੀਜ਼।
ਪੂਰੇ-ਟੀਮ ਯੋਜਨਾ 'ਚ ਫਸਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਮਾਂ-ਬਕਸਡ ਸਪਾਈਕ (3–10 ਦਿਨ) ਚਲਾਓ:
ਮਕਸਦ ਸੁਧਾਈ ਨਹੀਂ—ਬਲਕਿ ਰੋਡਬਲਾਕਰਸ ਨੂੰ ਜਲਦੀ ਸਾਹਮਣੇ ਲਿਆਉਣਾ ਹੈ (ਲਾਇਬ੍ਰੇਰੀ ਗੈਪ, ਬਿਲਡ ਮੁੱਦੇ, ਰਨਟਾਈਮ ਵਿਵਹਾਰ ਦੇ ਬਦਲਾਅ) ਅਤੇ ਦੂਧ ਸੂਚੀ-ਅਧਾਰਤ ਟਾਸਕਾਂ ਵਿੱਚ ਬਦਲਨਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਡਿਸਕਵਰੀ ਫੇਜ਼ ਨੂੰ ਤੇਜ਼ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ Koder.ai ਵਰਗੇ ਟੂਲ ਤੁਹਾਨੂੰ ਚੈਟ-ਚਲਿਤ ਵਰਕਫਲੋ ਦੁਆਰਾ ਇੱਕ ਅਪਗਰੇਡ ਪਾਥ يا ਰੀਰਾਈਟ ਸਲਾਇਸ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ—ਅਸਪੀਸ਼ੀ ਕਾਰਨਾਂ ਦੀ ਪ੍ਰੈਸ਼ਰ-ਟੈਸਟਿੰਗ ਲਈ, ਇੱਕ ਸਮਕਾਲੀ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਬਣਾਉਣ ਅਤੇ ਟੀਮ ਨੂੰ ਕਿਰਿਆਤਮਕ ਟਾਸਕ ਲਿਸਟ ਦੇਣ ਲਈ ਮਦਦਗਾਰ। Koder.ai React (web apps), backends (Go + PostgreSQL), ਅਤੇ mobile (Flutter) ਨੂੰ ਸਮਰਥਨ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਇੱਕ ਪ੍ਰਯੋਗਿਕ “ਨਵਾਂ ਬੇਜ਼ਲਾਈਨ” ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਨ ਦਾ ਪ੍ਰਯੋਗੀ ਰਾਹ ਹੋ ਸਕਦਾ ਹੈ ਜਦ ਕਿ ਲੇਗੇਸੀ ਸਿਸਟਮ ਸਥਿਰ ਰਹੇ।
ਅਪਗਰੇਡ ਅਸਫਲ ਹੁੰਦੇ ਹਨ ਜਦ ਹਰ ਚੀਜ਼ “ਮਾਈਗ੍ਰੇਸ਼ਨ” ਵਿੱਚ ਗੂੰਝੀ ਹੋਈ ਹੋਵੇ। ਯੋਜਨਾ ਨੂੰ ਵੱਖ-ਵੱਖ ਵਰਕਸਟਰੀਮਾਂ ਵਿੱਚ ਵੰਡੋ:
ਇਸ ਨਾਲ ਅੰਦਾਜ਼ੇ ਜ਼ਿਆਦਾ ਯੋਗ-ਵਿਸ਼ਵਾਸ਼ਯੋਗ ਬਣ ਜਾਂਦੇ ਹਨ ਅਤੇ ਉਹ ਥਾਂ ਦਰਸਾਉਂਦੇ ਹਨ ਜਿੱਥੇ ਤੁਸੀਂ ਘੱਟ ਨਿਵੇਸ਼ ਕਰ ਰਹੇ ਹੋ (ਅਕਸਰ ਟੈਸਟ ਅਤੇ ਰੋਲਆਊਟ)।
“ਵੱਡਾ ਸਵਿਚ” ਕਰਨ ਦੀ ਬਜਾਏ, ਨਿਯੰਤਰਿਤ ਡਿਲਿਵਰੀ ਤਕਨੀਕਾਂ ਵਰਤੋ:
ਪ੍ਰਾਰੰਭ ਤੋਂ ਹੀ ਨਿਰਵੇਖਣ ਦੀ ਯੋਜਨਾ ਬਣਾਓ: ਕਿਹੜੇ ਮੈਟ੍ਰਿਕਸ ‘ਸੇਫ਼’ ਹਨ, ਅਤੇ ਕੀ ਟ੍ਰਿਗਰ ਰੋਲਬੈਕ ਕਰੇਗਾ।
ਅੱਪਡੇਟ ਨੂੰ ਨਤੀਜਿਆਂ ਅਤੇ ਖਤਰਾ-ਨਿਯੰਤਰਣਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਵਿਆਖਿਆ ਕਰੋ: ਕੀ ਸੁਧਾਰੇਗਾ (ਸੁਰੱਖਿਆ ਸਹਿਯੋਗ, ਤੇਜ਼ ਡਿਲਿਵਰੀ), ਕੀ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਢੀਲਾ ਹੋ ਸਕਦਾ (ਟੈਮਪੋਰੇਰੀ ਵੈਲੋਸਿਟੀ ਡ੍ਰਾਪ), ਅਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਮੈਨੇਜ ਕਰ ਰਹੇ ਹੋ (ਸਪਾਈਕ ਨਤੀਜੇ, ਧੀਰੇ ਰੋਲਆਊਟ, ਸਪਸ਼ਟ go/no-go ਚੈਕਪੋਇੰਟ)।
ਟਾਈਮਲਾਈਨਾਂ ਨੂੰ ਅਨੁਮਾਨਾਂ ਨਾਲ ਸਾਂਝਾ ਕਰੋ ਅਤੇ ਪ੍ਰਗਟੀ ਨੂੰ ਵਰਕਸਟਰੀਮ ਮੁਤਾਬਕ ਸਧਾਰਨ ਸਥਿਤੀ ਦਰਸਾਓ।
ਸਭ ਤੋਂ ਸਸਤਾ ਅਪਗ੍ਰੇਡ ਉਹ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਕਦੇ ਵੱਡਾ ਨਹੀਂ ਬਣਨ ਦਿੰਦੇ। ਜ਼ਿਆਦਾਤਰ ਦਰਦ ਸਾਲਾਂ ਦੀ ਡ੍ਰਿਫਟ ਤੋਂ ਹੁੰਦੀ ਹੈ: ਡਿਪੈਂਡੈਂਸੀਜ਼ ਪੁਰਾਣੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਪੈਟਰਨ ਵਿਭਿੰਨ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਅਪਗਰੇਡ ਇੱਕ ਮਲਟੀ-ਮਹੀਨੇ ਖਣਨ ਕਾਰਜ ਬਣ ਜਾਂਦਾ ਹੈ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਅੱਪਡੇਟ ਰੁਟਿਨ, ਛੋਟੇ, ਅਤੇ ਘੱਟ-ਖੱਤਰ ਵਾਲੇ ਬਣ ਜਾਣ।
ਫਰੇਮਵਰਕ ਅਤੇ ਡਿਪੈਂਡੈਂਸੀ ਅੱਪਡੇਟ ਨੂੰ ਵਾਲਵ ਤੇਲ ਬਦਲਣ ਵਾਂਗ ਗਿਣੋ, ਨਾਂ ਕਿ ਇੰਜਨ ਰੀਬਿਲਡ। ਰੋਡਮੇਪ 'ਤੇ ਇਕ ਰੀਕਰਿੰਗ ਆਈਟਮ ਰੱਖੋ—ਕੁਆਰਟਰਲੀ ਹਰ ਇੱਕ ਟੀਮ ਲਈ ਇੱਕ ਪ੍ਰਯੋਗੀ ਸ਼ੁਰੂਆਤ।
ਇੱਕ ਸਿੱਧਾ ਨਿਯਮ: ਹਰ ਕਵਾਰਟਰ ਕੁਝ ਸਮਰੱਥਾ (ਅਕਸਰ 5–15%) ਸੰਰੱਖਿਤ ਕਰੋ ਵਰਜਨ ਬੰਪ, ਡੀਪ੍ਰੇਕੇਸ਼ਨ ਅਤੇ ਸਾਫ਼-ਸੁਥਰਾ ਕੰਮ ਲਈ। ਇਹ ਪੂਰਣਤਾ ਬਾਰੇ ਨਹੀਂ, ਬਲਕਿ ਕਈ ਸਾਲਾਂ ਦੇ ਗੈਪ ਨੂੰ ਰੋਕਣ ਬਾਰੇ ਹੈ ਜੋ ਉੱਚ-ਸਟੇਕ ਮਾਈਗਰੇਸ਼ਨ ਨੂੰ ਮજબੂਰ ਕਰਦੇ ਹਨ।
ਡਿਪੈਂਡੈਂਸੀ ਆਹਿਸਤਾ-ਆਹਿਸਤਾ ਸੜਾਉਂਦੀਆਂ ਹਨ। ਥੋੜ੍ਹੀ ਹਾਈਜੀਨ ਤੁਹਾਡੇ ਐਪ ਨੂੰ “ਮੌਜੂਦਾ” ਨੇੜੇ ਰੱਖਦੀ ਹੈ, ਤਾਂ ਜੋ ਅੱਗਲਾ ਫਰੇਮਵਰਕ ਅਪਗਰੇਡ ਇੱਕ ਚੇਨ-ਰੀਐਕਸ਼ਨ ਨਾ ਬਣੇ।
ਨਵੇਂ ਫੀਚਰਾਂ ਲਈ “ਮੰਨਿਆ ਡਿਪੈਂਡੈਂਸੀਜ਼” ਦੀ ਛੋਟੀ-ਸੂਚੀ ਬਣਾਉਣ 'ਤੇ ਵੀ ਵਿਚਾਰ ਕਰੋ। ਘੱਟ, ਵਧੀਆ-ਸਮਰਥਿਤ ਲਾਇਬ੍ਰੇਰੀਜ਼ ਭਵਿੱਖ ਦੇ ਅਪਗਰੇਡ ਘਰਾਵਟ ਘਟਾਉਂਦੀਆਂ ਹਨ।
ਤੁਹਾਨੂੰ ਪਰਫੈਕਟ ਕਵਰੇਜ ਦੀ ਲੋੜ ਨਹੀਂ—ਤੁਹਾਨੂੰ ਮਹੱਤਵਪੂਰਨ ਪਾਥਾਂ 'ਤੇ ਭਰੋਸਾ ਚਾਹੀਦਾ ਹੈ। ਉਨ੍ਹਾਂ ਫਲੋਜ਼ ਦੇ ਆਲੇ- ਦੁਆਲੇ ਟੈਸਟ ਬਣਾਓ ਜਿਨ੍ਹਾਂ ਦਾ ਟੁੱਟਣਾ ਮਹਿੰਗਾ ਪੈ ਸਕਦਾ ਹੈ: sign-up, checkout, billing, permissions, ਅਤੇ ਮੁੱਖ ਇੰਟੇਗ੍ਰੇਸ਼ਨ।
ਇਸਨੂੰ ਲਗਾਤਾਰ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਅੱਗੇ-ਆਪਗਰੇਡ ਤੋਂ ਪਹਿਲਾਂ ਟੈਸਟ ਜੋੜਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਦਬਾਅ ਹੇਠ ਲਿਖ ਰਹੇ ਹੋਵੋਗੇ, ਜਦ ਅਪਗਰੇਡ ਹੀ ਚੇਜ਼ਜ਼ ਦੌੜਾ ਰਹੇ ਹੋਵਾਂਗੇ।
ਪੈਟਰਨ ਸਟੈਂਡਰਡ ਕਰੋ, ਮਰੇ কোਡ ਨੂੰ ਹਟਾਓ, ਅਤੇ ਅਹਿਮ ਫੈਸਲਿਆਂ ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਓ ਜਿਵੇਂ-ਜਿਵੇਂ ਤੁਸੀਂ ਜਾ ਰਹੇ ਹੋ। ਅਸਲ ਉਤਪਾਦ ਕੰਮ ਨਾਲ ਜੁੜੇ ਛੋਟੇ ਰੀਫੈਕਟਰਿੰਗ ਨੂੰ ਜ਼ਿਆਦਾ ਆਸਾਨ ਤਰੱਕੀ ਮਿਲਦੀ ਹੈ ਅਤੇ ਉਹ “ਅਣਜਾਣੀਆਂ” ਨੂੰ ਘੱਟ ਕਰਦੇ ਹਨ ਜੋ ਅਪਗਰੇਡ ਅੰਦਾਜ਼ੇ ਨੂੰ ਫੈਲਾ ਦਿੰਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਅਸੀਂ ਦੂਜਾ ਰਾਯ ਦਿਇਏ ਕਿ ਅਪਡੇਟ, ਰੀਫੈਕਟਰ ਜਾਂ ਰੀਰਾਈਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ—ਅਤੇ ਇਸਨੂੰ ਕਿਵੇਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸਟੇਜ ਕਰਨਾ ਹੈ—ਅਸੀਂ ਤੁਹਾਡੇ ਲਈ ਵਿਕਲਪਾਂ ਦਾ ਮੂਲਾਂਕਣ ਅਤੇ ਇੱਕ ਵਿਆਵਹਾਰਿਕ ਯੋਜਨਾ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹਾਂ। Reach out at /contact.
ਇੱਕ ਅੱਪਡੇਟ ਮੌਜੂਦਾ ਸਿਸਟਮ ਦੀ ਮੁੱਖ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਵਰਤੋਂ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹੋਏ ਨਵੇਂ ਫਰੇਮਵਰਕ ਵਰਜਨ 'ਤੇ ਲਿਜਾਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਹੁੰਦੀ ਹੈ। ਖ਼ਰਚ ਆਮ ਤੌਰ 'ਤੇ ਖਤਰੇ ਅਤੇ ਛੁਪੇ ਹੋਏ ਜੋੜਾਂ ਨਾਲ ਨਿਰਧਾਰਤ ਹੁੰਦਾ ਹੈ: ਡਿਪੈਂਡੈਂਸੀ ਟਕਰਾਅ, ਬਿਹੈਵੀਅਰ ਬਦਲਾਅ, ਅਤੇ ਇਕ ਸਥਿਰ ਬੇਜ਼ਲਾਈਨ ਮੁੜ-ਸਥਾਪਿਤ ਕਰਨ ਲਈ ਲੋੜੀਦਾ ਕੰਮ (auth, routing, build tooling, observability), ਨਾ ਕਿ ਸਿਰਫ਼ ਫਾਇਲਾਂ ਦੀ ਗਿਣਤੀ।
ਮੁੱਖ ਅੱਪਡੇਟਾਂ ਵਿੱਚ ਅਕਸਰ ਬ੍ਰੇਕਿੰਗ API ਬਦਲਾਅ, ਨਵੇਂ ਡਿਫਾਲਟ ਅਤੇ ਲਾਜ਼ਮੀ ਮਾਈਗਰੇਸ਼ਨ ਹੁੰਦੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਸਟੈਕ 'ਤੇ ਲਹਿਰਾਂ ਵਾਂਗ ਫੈਲਦੇ ਹਨ.
ਹਾਲਾਂਕਿ ਐਪ “ਬਿਲਡ” ਹੋ ਸਕਦੀ ਹੈ, ਨਰਮ ਬਿਹੇਵियर ਬਦਲਾਅ ਵੱਡੇ ਰੀਫੈਕਟਰਨਗ ਅਤੇ ਵਿਆਪਕ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟਿੰਗ ਦੀ ਮੰਗ ਕਰ ਸਕਦੇ ਹਨ ਤਾਂ ਕਿ ਇਹ ਸਾਬਤ ਕੀਤਾ ਜਾ ਸਕੇ ਕਿ ਕੋਈ ਮਹੱਤਵਪੂਰਨ ਫੰਕਸ਼ਨ ਟੁੱਟਿਆ ਨਹੀਂ।
ਟੀਮਾਂ ਅਕਸਰ ਅੱਪਡੇਟ ਮੁਲਤਵੀ ਕਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਫੀਚਰ ਰੋਡਮੇਪ ਗਾਹਕਾਂ ਲਈ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਉਤਪਾਦਤਾ ਨੂੰ ਇਨਾਮ ਦਿੰਦੇ ਹਨ, ਜਦਕਿ ਅੱਪਡੇਟ ਬਿਨਾਂ ਸਿੱਧੇ ਲਾਭਾਂ ਵਾਲੇ ਲੱਗਦੇ ਹਨ.
ਸੰਯੁਕਤ ਰੋਕਾਵਟਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਜਦੋਂ ਫਰੇਮਵਰਕ ਨਵੇਂ ਰਨਟਾਈਮ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ ਤਾਂ ਆਸ-ਪਾਸ ਦੀਆਂ ਚੀਜ਼ਾਂ ਵੀ ਅੱਪਡੇਟ ਹੋਣ ਲੱਗਦੀਆਂ ਹਨ: Node/Java/.NET ਵਰਜਨ, ਬਿਲਡ ਟੂਲਿੰਗ, ਬੰਡਲਰ, ਟੈਸਟ ਰਨਰ, ਲਿਨਟਰ ਅਤੇ CI ਸਕ੍ਰਿਪਟ।
ਇਸ ਲਈ ਇੱਕ ‘ਅੱਪਡੇਟ’ ਅਕਸਰ ਇੱਕ ਟੂਲਚੇਨ ਐਲਾਇਨਮੈਂਟ ਪ੍ਰੋਜੈਕਟ ਬਣ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਸੰਰਚਨਾ ਅਤੇ ਅਨੁਕੂਲਤਾ ਡਿਬੱਗਿੰਗ ਲਈ ਸਮਾਂ ਲੱਗਦਾ ਹੈ।
ਡਿਪੈਂਡੈਂਸੀਆਂ ਰੋਕ ਟੋਕ ਕਰ ਸਕਦੀਆਂ ਹਨ ਜਦ:
ਡਿਪੈਂਡੈਂਸੀ ਬਦਲਣਾ ਆਮ ਤੌਰ 'ਤੇ ਸਧਾਰਨ ਸੁਇਚ ਨਹੀਂ ਹੁੰਦਾ—ਇਸ ਦਾ ਮਤਲਬ ਇੱਕਨੇਕ ਇੰਟੇਗ੍ਰੇਸ਼ਨ ਬਿੰਦੂਆਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ, ਵਿਹਾਰ ਨੂੰ ਦੁਬਾਰਾ ਵੈਰੀਫਾਈ ਕਰਨਾ ਅਤੇ ਟੀਮ ਲਈ ਦਸਤਾਵੇਜ਼ ਅਪਡੇਟ ਕਰਨਾ ਹੁੰਦਾ ਹੈ।
ਕੁਝ ਬ੍ਰੇਕਿੰਗ ਚੇਜ਼਼ ਆਵਾਜ਼ ਵਾਲੇ ਹੁੰਦੇ ਹਨ (ਬਿਲਡ ਫੇਲ ਹੋਣਾ)। ਹੋਰ ਨਰਮ ਹੁੰਦੇ ਹਨ: ਕਠੋਰ ਵੈਲਿਡੇਸ਼ਨ, ਵੱਖਰੇ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਫਾਰਮੈਟ, ਟਾਈਮਿੰਗ ਬਦਲਾਅ ਜਾਂ ਨਵੇਂ ਸੁਰੱਖਿਆ ਡਿਫਾਲਟ ਜੋ ਰੀਗ੍ਰੈਸ਼ਨ ਬਣਾਅ ਸਕਦੇ ਹਨ.
ਪ੍ਰਯੋਗੀ ਰਾਹ:
ਟੈਸਟਿੰਗ ਸੁਰੱਖਿਆ ਜਾਲ ਹੈ—ਪਰ ਇਹੀ ਓਹ ਥਾਂ ਹੈ ਜਿਥੇ ਅੱਪਡੇਟ ਬਜਟ ਚੁੱਪਚਾਪ ਫੈਲਦੇ ਹਨ। ਅਕਸਰ ਟੀਮਾਂ ਨੂੰ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਦੀ ਆਟੋਮੈਟਡ ਕਵਰੇਜ ਪਤਲੀ, ਬਹਿ-ਰੁਝੀਵਾਲੀ ਜਾਂ ਗਲਤ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਰੱਖਦੀ ਹੈ।
ਅੱਪਡੇਟ ਦੌਰਾਨ ਟੈਸਟਿੰਗ ਅਕਸਰ ਇਨ੍ਹਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਮੰਗਦੀ ਹੈ:
ਜੇ ਆਟੋਮੇਟਿਕ ਕਵਰੇਜ ਘੱਟ ਹੈ ਤਾਂ ਮੈਨੁਅਲ QA, UAT ਅਤੇ ਕੋਆਰਡੀਨੇਸ਼ਨ ਵਧ ਜਾਂਦੇ ਹਨ—ਇਹੀ ਅਸਲ ਬਜਟ ਖਾਣ ਵਾਲੀ ਚੀਜ਼ ਹੈ।
ਅੱਪਡੇਟ ਉਹਨਾਂ ਛੁਪੇ ਹੋਏ শরਟਕੱਟਾਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਂਦਾ ਹੈ ਜਿਹੜੇ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਲਈ ਲਏ ਗਏ ਸਨ—ਦਾੜੀਓਂ ਦੀ ਵਾਂਗ ਇਹ ‘ਸੁਦ’ ਵਾਪਸ ਮੰਗਦਾ ਹੈ। ਇਹ ਸ਼ੌਰਟਕੱਟ monkey patches, ਕਸਟਮ ਫੋਰਕ, ਡਾਇਰੈਕਟ DOM ਐਕਸੈਸ ਜਾਂ ਐਸੇ ਹਥਕੰਡੇ ਹੋ ਸਕਦੇ ਹਨ ਜੋ ਨਵੇਂ ਸੁਰੱਖਿਆ ਜਾਂ ਆਰਕੀਟੈਕਚਰ ਮਾਡਲ ਨਾਲ ਨਹੀਂ ਮੇਲ ਖਾਂਦੇ।
ਅੱਪਡੇਟ ਦੌਰਾਨ ‘ਬਿਹੇਵਿਅਰ ਇੱਕੋ ਜਿਹਾ ਰੱਖਣਾ’ ਹੋਰ ਵੀ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਫਰੇਮਵਰਕ ਦੇ ਨਿਯਮ ਬਦਲ ਰਹੇ ਹੁੰਦੇ ਹਨ—ਤੁਸੀਂ ਬਣਾਉਣ ਦੀ ਨਹੀਂ, ਬਚਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ।
ਕਈ ਵਾਰੀ ਰੀਰਾਈਟ ਆਸਾਨ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇਰਾਦੇ ਨੂੰ ਦੁਬਾਰਾ ਲਾਗੂ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ, ਨਾ ਕਿ ਹਰ ਇੱਕ ਇਤਿਹਾਸਿਕ ਗਲਤੀ ਦੀ ਰੱਖਿਆ।
ਲੰਮੇ ਅੱਪਡੇਟ ਇੱਕ ਪਿਛੋਕੜ ਕੰਮ ਬਣ ਜਾਂਦੇ ਹਨ ਜੋ ਉਤਪਾਦਕਾਰੀ ਤੋਂ ਧਿਆਨ ਖਿੱਚਦੇ ਹਨ। ਇੱਥੇ ਕੁਝ ਪ੍ਰਭਾਵ ਹਨ:
ਇੱਕ ਵਧੀਆ ਮਾਤਰ ਪ੍ਰਮਾਣ ਹੈ “ਵੈਲੋਸਿਟੀ ਟੈਕਸ”: ਜੇ ਟੀਮ ਪਹਿਲਾਂ 10 ਪ्वਾਇੰਟ ਪ੍ਰਤੀ ਸਪ੍ਰਿੰਟ ਭੇਜਦੀ ਸੀ ਅਤੇ ਅੱਪਗਰੇਡ ਦੌਰਾਨ ਇਹ 6 ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਤੁਸੀਂ ਲਗਭਗ 40% ਟੈਕਸ ਦੇ ਰਹੇ ਹੋ।
ਅੱਪਡੇਟ ਜਿੱਤਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਚੰਗੇ ਟੈਸਟ, ਛੋਟਾ ਵਰਜਨ ਗੈਪ, ਅਤੇ ਸਾਫ਼ ਬਾਉਂਡਰੀਜ਼ ਹੋਣ ਜੋ ਤੁਹਾਨੂੰ ਟੁਕੜਿਆਂ ਵਿੱਚ ਅੱਪਡੇਟ ਕਰਨ ਨੂਂ ਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਰੀਰਾਈਟ ਅਕਸਰ ਸਸਤਾ ਪੈਂਦਾ ਹੈ ਜਦ:
ਕਿਸੇ ਵੀ ਫੈਸਲੇ ਤੋਂ ਪਹਿਲਾਂ 1–2 ਹਫ਼ਤੇ ਦੀ ਡਿਸਕਵਰੀ ਕਰੋ: ਇੱਕ ਨਮੂਨੀ ਫੀਚਰ ਅੱਪਗਰੇਡ ਕਰੋ, ਡਿਪੈਂਡੈਂਸੀਜ਼ ਦੀ ਇਨਵੈਂਟਰੀ ਬਣਾਓ, ਅਤੇ ਗਵਾਹੀ ਨਾਲ ਐਫੋਰਟ ਅੰਦਾਜ਼ਾ ਲਵੋ।
