ਇੱਕ ਤਾਜ਼ਾ ਡਿਪਲਾਈਮੈਂਟ (deployment) ਨੇ ਤਿੰਨ ਮਾਈਕਰੋਸਰਵਿਸਿਜ਼ (microservices) ਨੂੰ ਤੋੜ ਦਿੱਤਾ, ਭਾਵੇਂ ਹਰ ਯੂਨਿਟ ਟੈਸਟ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟ ਅਤੇ ਮੌਕ-ਸਰਵਰ ਚੈੱਕ ਪਾਸ ਹੋ ਗਏ ਸਨ। ਟੀਮ ਨੇ ਆਪਣੇ API ਮੌਕਸ ਨੂੰ ਕੰਟਰੈਕਟ ਟੈਸਟਿੰਗ (contract testing) ਨਾਲ ਬਦਲ ਦਿੱਤਾ। ਛੇ ਮਹੀਨਿਆਂ ਵਿੱਚ, ਕੰਟਰੈਕਟ ਦੀ ਗਿਣਤੀ ਤਿੰਨ ਤੋਂ ਵਧ ਕੇ 47 ਹੋ ਗਈ ਅਤੇ ਮਹੀਨਾਵਾਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ-ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਦਰ ਦੋ ਘਟਨਾਵਾਂ ਤੋਂ ਘਟ ਕੇ ਜ਼ੀਰੋ ਹੋ ਗਈ।

ਮੌਕਸ (mocks) ਤੁਹਾਨੂੰ ਕਿਉਂ ਨਹੀਂ ਬਚਾ ਸਕਦੇ

ਇੱਕ ਮੌਕ ਸਰਵਰ ਸਿਰਫ਼ ਉਸ ਰੂਪ (shape) ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ ਜਿਸਦੀ ਇੱਕ ਕੰਜ਼ਿਊਮਰ (consumer) ਉਮੀਦ ਕਰਦਾ ਹੈ; ਇਹ ਕਦੇ ਵੀ ਇਹ ਚੈੱਕ ਨਹੀਂ ਕਰਦਾ ਕਿ ਪ੍ਰੋਵਾਈਡਰ (provider) ਅਸਲ ਵਿੱਚ ਉਹ ਰੂਪ ਪ੍ਰਦਾਨ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਜੇਕਰ ਕੋਈ ਪ੍ਰੋਵਾਈਡਰ ਕਿਸੇ ਫੀਲਡ ਦਾ ਨਾਮ ਬਦਲਦਾ ਹੈ—ਮੰਨ ਲਓ name ਤੋਂ display_name ਵਿੱਚ—ਤਾਂ ਮੌਕ ਅਜੇ ਵੀ ਪੁਰਾਣਾ ਪੇਲੋਡ (payload) ਵਾਪਸ ਕਰਦਾ ਹੈ, ਕੰਜ਼ਿਊਮਰ ਦੇ ਟੈਸਟ ਹਰੇ (green) ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਲਾਈਵ ਸਿਸਟਮ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ। ਮੰਗਲਵਾਰ ਨੂੰ ਦੁਪਹਿਰ 2 ਵਜੇ ਹੋਈ ਪ੍ਰੋਡਕਸ਼ਨ ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਘਟਨਾ ਬਿਲਕੁਲ ਅਜਿਹੀ ਹੀ ਸੀ: ਮੌਕ ਨੇ ਅਸਲ ਕੰਟਰੈਕਟ ਬਾਰੇ "ਝੂਠ" ਬੋਲਿਆ ਸੀ।

ਕੰਟਰੈਕਟ ਟੈਸਟਿੰਗ ਖਾਲੀ ਥਾਂ ਨੂੰ ਭਰਦੀ ਹੈ

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

  • Consumer-driven contracts – ਕੰਜ਼ਿਊਮਿੰਗ ਸਰਵਿਸ ਉਮੀਦਾਂ ਲਿਖਦੀ ਹੈ; ਪ੍ਰੋਵਾਈਡਿੰਗ ਸਰਵਿਸ ਉਹਨਾਂ ਦੀ ਪੁਸ਼ਟੀ (validate) ਕਰਦੀ ਹੈ। ਇਹ ਉਹਨਾਂ ਅੰਦਰੂਨੀ ਮਾਈਕਰੋਸਰਵਿਸਿਜ਼ ਲਈ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜੋ ਇਕੱਠੇ ਵਿਕਸਿਤ ਹੁੰਦੀਆਂ ਹਨ।
  • Provider-driven contracts – ਪ੍ਰੋਵਾਈਡਰ ਇੱਕ ਸਪੈਸੀਫਿਕੇਸ਼ਨ (specification) ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ; ਕੰਜ਼ਿਊਮਰ ਇਸ ਦੇ ਵਿਰੁੱਧ ਆਪਣੇ ਕੋਡ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ। ਇਹ ਪਬਲਿਕ API ਲਈ ਆਮ ਪੈਟਰਨ ਹੈ।

ਪਹਿਲਾ ਤਰੀਕਾ ਆਮ ਤੌਰ 'ਤੇ ਮਾਈਕਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ ਦੇ ਅੰਦਰ ਟੁੱਟੇ ਹੋਏ ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ।

ਕੰਜ਼ਿਊਮਰ-ਡਰਿਵਨ ਕੰਟਰੈਕਟ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

  1. ਕੰਜ਼ਿਊਮਰ ਇੱਕ ਟੈਸਟ ਲਿਖਦਾ ਹੈ ਜੋ ਬਿਲਕੁਲ ਦੱਸਦਾ ਹੈ ਕਿ ਉਸਨੂੰ ਪ੍ਰੋਵਾਈਡਰ ਤੋਂ ਕੀ ਚਾਹੀਦਾ ਹੈ।
  2. ਟੈਸਟ ਚਲਾਉਣ ਨਾਲ ਇੱਕ pact file ਬਣਦੀ ਹੈ – ਇੱਕ JSON ਦਸਤਾਵੇਜ਼ ਜੋ ਉਹਨਾਂ ਉਮੀਦਾਂ ਨੂੰ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ।
  3. ਪ੍ਰੋਵਾਈਡਰ ਆਪਣੇ CI ਪਾਈਪਲਾਈਨ ਵਿੱਚ pact file ਦੇ ਵਿਰੁੱਧ ਆਪਣੀ ਅਸਲ ਸਰਵਿਸ ਚਲਾਉਂਦਾ ਹੈ।
  4. ਜੇਕਰ ਪ੍ਰੋਵਾਈਡਰ ਕਿਸੇ ਫੀਲਡ ਨੂੰ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਵੈਰੀਫਿਕੇਸ਼ਨ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਬਿਲਡ ਰੋਕ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

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

ਤੁਹਾਡੇ ਟੈਸਟ ਪਿਰਾਮਿਡ ਵਿੱਚ ਕੰਟਰੈਕਟ ਟੈਸਟ ਕਿੱਥੇ ਆਉਂਦੇ ਹਨ

  • Unit tests – ਤੇਜ਼, ਅਲੱਗ-ਅਲੱਗ (isolated) ਲੌਜਿਕ ਦਾ ਟੈਸਟ ਕਰਦੇ ਹਨ।
  • Contract tests – ਦਰਮਿਆਨੀ ਗਤੀ, ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ ਕਿ API ਸਮਝੌਤੇ ਬਣੇ ਰਹਿੰਦੇ ਹਨ।
  • End-to-end tests – ਹੌਲੀ, ਪੂਰੇ ਬਿਜ਼ਨਸ ਫਲੋਅ (flows) ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ।

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

ਅਸਲ ਦੁਨੀਆ ਦੀ ਅਪਣਾਉਣ ਦੀ ਕਹਾਣੀ

ਉਹ ਟੀਮ ਜਿਸਨੇ ਇਸ ਲੇਖ ਦੀ ਸ਼ੁਰੂਆਤ ਕੀਤੀ, ਤਿੰਨ ਕੰਟਰੈਕਟਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੋਈ ਸੀ ਜੋ ਉਹਨਾਂ ਦੀਆਂ ਸਭ ਤੋਂ ਨਾਜ਼ੁਕ ਕਾਲਾਂ (calls) ਨੂੰ ਕਵਰ ਕਰਦੇ ਸਨ। ਛੇ ਮਹੀਨਿਆਂ ਬਾਅਦ, ਉਹਨਾਂ ਕੋਲ 47 ਕੰਟਰੈਕਟ ਸਨ ਜੋ ਜ਼ਿਆਦਾਤਰ ਇੰਟਰ-ਸਰਵਿਸ ਟ੍ਰੈਫਿਕ ਨੂੰ ਕਵਰ ਕਰਦੇ ਸਨ। ਉਸ ਦੌਰਾਨ API ਟੁੱਟਣ ਦੀਆਂ ਘਟਨਾਵਾਂ ਮਹੀਨੇ ਦੀਆਂ ਦੋ ਤੋਂ ਘਟ ਕੇ ਜ਼ੀਰੋ ਹੋ ਗਈਆਂ।

ਜਦੋਂ ਕੰਟਰੈਕਟ ਟੈਸਟਿੰਗ ਫਾਇਦੇਮੰਦ ਨਹੀਂ ਹੋ ਸਕਦੀ

  • ਤੁਸੀਂ ਇੱਕ ਸੋਲੋ ਡਿਵੈਲਪਰ ਹੋ ਜੋ ਸਾਰੀਆਂ ਸਰਵਿਸਿਜ਼ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਰਿਪੋਜ਼ਟਰੀ (repository) ਵਿੱਚ ਰੱਖਦੇ ਹੋ।
  • API ਬਹੁਤ ਹੀ ਸਥਿਰ ਹੈ ਅਤੇ ਸਾਲਾਂ ਤੋਂ ਬਦਲੀ ਨਹੀਂ ਹੋਈ ਹੈ।
  • ਤੁਸੀਂ ਇੱਕ ਅਜਿਹਾ ਪ੍ਰੋਟੋਟਾਈਪ (prototype) ਬਣਾ ਰਹੇ ਹੋ ਜਿਸ ਨੂੰ ਜਲਦੀ ਹੀ ਸੁੱਟ ਦਿੱਤਾ ਜਾਵੇਗਾ।

ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ, ਕੰਟਰੈਕਟਾਂ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਦਾ ਵਾਧੂ ਕੰਮ (overhead) ਫਾਇਦੇ ਨਾਲੋਂ ਵੱਧ ਹੋ ਸਕਦਾ ਹੈ।

ਸੰਭਾਵੀ ਨੁਕਸਾਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਘਟਾਇਆ ਜਾਵੇ

  • ਕੰਟਰੈਕਟਾਂ ਨੂੰ ਉਹਨਾਂ ਕੋਡ ਦੇ ਨਾਲ ਵਰਜ਼ਨਡ (versioned) ਰੱਖੋ ਜਿਸਦਾ ਉਹ ਵਰਣਨ ਕਰਦੇ ਹਨ।
  • ਪੁਰਾਣੇ (stale) ਕੰਟਰੈਕਟਾਂ ਤੋਂ ਬਚਣ ਲਈ ਹਰ CI ਰਨ ਵਿੱਚ ਵੈਰੀਫਿਕੇਸ਼ਨ ਨੂੰ ਆਟੋਮੇਟ ਕਰੋ।
  • ਅਚਾਨਕ ਹੋਣ ਵਾਲੇ ਟੁੱਟਣ ਨੂੰ ਫੜਨ ਲਈ ਪਲ ਰਿਕੁਐਸਟਾਂ (pull requests) ਵਿੱਚ ਕੰਟਰੈਕਟ ਤਬਦੀਲੀਆਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ।

ਸਿੱਖਿਆ (Takeaway)

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