ਇਕ ਕਦਮ-ਦਰ-ਕਦਮ ਗਾਈਡ: ਕੀ ਯੋਜਨਾ ਬਣਾਉਣੀ ਹੈ, ਕਿਵੇਂ ਬਣਾਉਣਾ ਹੈ, ਅਤੇ ਇੱਕ ਅੰਦਰੂਨੀ ਡਿਵੈਲਪਰ ਪਲੇਟਫਾਰਮ ਲਈ ਵੈੱਬ ਐਪ ਨੂੰ ਕਿਵੇਂ ਸ਼ਿਪ ਕਰਨਾ ਹੈ — ਕੈਟਾਲਾਗ, ਟੈਮਪਲੇਟ, ਵਰਕਫਲੋਜ਼, ਪਰਮੀਸ਼ਨ, ਅਤੇ ਆਡੀਟਬਿਲਟੀ।
IDP ਵੈੱਬ ਐਪ ਤੁਹਾਡੇ ਇੰਜਨੀਅਰਿੰਗ ਸਿਸਟਮ ਲਈ ਇੱਕ ਅੰਦਰੂਨੀ “ਫਰੰਟ ਡੋਰ” ਹੈ। ਇਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਡਿਵੈਲਪਰ ਵੇਖਦੇ ਹਨ ਕਿ ਪਹਿਲਾਂ ਕੀ ਮੌਜੂਦ ਹੈ (ਸਰਵਿਸਾਂ, ਲਾਇਬ੍ਰੇਰੀਆਂ, ਇਨਵਾਇਰਨਮੈਂਟ), ਪ੍ਰਸਿੱਧ ਤਰੀਕੇ ਨਾਲ ਸਾਫਟਵੇਅਰ ਬਣਾਉਣ ਤੇ ਚਲਾਉਣ ਲਈ ਪ徉ਾਇਓਂ ਦੀ ਪਾਲਨਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਬਿਨਾਂ ਢੇਰ ਸਾਰਿਆਂ ਟੂਲਾਂ ਵਿੱਚ ਖੋਜੇ ਬਦਲਾਵਾਂ ਦੀ ਬੇਨਤੀ ਕਰਦੇ ਹਨ।
ਇਹੋ ਜਿੰਨੀ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ Git, CI, ਕਲਾਊਡ ਕੰਸੋਲ ਜਾਂ ਟਿਕਟਿੰਗ ਦਾ ਇੱਕ ਹੋਰ ਸਭ-ਇੱਕ ਬਦਲ ਨਹੀਂ ਹੈ। ਮਕਸਦ ਮੌਜੂਦਾ ਉਪਕਰਣਾਂ ਨੂੰ ਆਰਕੀਸਟਰੇਟ ਕਰਕੇ ਰੁਕਾਵਟ ਘਟਾਉਣਾ ਹੈ—ਸਹੀ ਰਾਹ ਨੂੰ ਸਭ ਤੋਂ ਆਸਾਨ ਰਾਹ ਬਣਾਉਣਾ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਇੱਕ IDP ਵੈੱਬ ਐਪ ਤਾਂ ਬਣਾਉਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਰੋਜ਼ਾਨਾ ਕੰਮ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਕਾਰਨਾਂ ਕਰਕੇ ਹੌਲੀਆਂ ਹੋ ਜਾਂਦਾ ਹੈ:
ਵੈੱਬ ਐਪ ਨੂੰ ਇਹਨਾਂ ਨੂੰ ਦੁਹਰਣਯੋਗ ਵਰਕਫਲੋਜ਼ ਅਤੇ ਸਪਸ਼ਟ, ਖੋਜੇ-ਜਾ ਸਕਣ ਵਾਲੀ ਜਾਣਕਾਰੀ ਵਿੱਚ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਸ਼ੀਲ IDP ਵੈੱਬ ਐਪ ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਹਿੱਸਿਆਂ ਵਿੱਚ ਹੁੰਦਾ ਹੈ:
ਪਲੇਟਫਾਰਮ ਟੀਮ ਆਮ ਤੌਰ 'ਤੇ ਪੋਰਟਲ ਪ੍ਰੋਡਕਟ ਦੀ ਮਾਲਕੀ ਰੱਖਦੀ ਹੈ: ਅਨੁਭਵ, APIs, ਟੈਮਪਲੇਟ, ਅਤੇ ਗਾਰਡਰੇਲਸ।
ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਆਪਣੀਆਂ ਸਰਵਿਸਾਂ ਦੀ ਮਾਲਕੀ ਰੱਖਦੀਆਂ ਹਨ: ਮੈਟਾਡੇਟਾ ਸਹੀ ਰੱਖਣਾ, ਡੌਕਸ/ਰਨਬੁੱਕ ਨਿਵੜਣਾ, ਅਤੇ ਦਿੱਤੇ ਟੈਮਪਲੇਟ ਅਪਨਾਉਣਾ। ਇੱਕ ਸਿਹਤਮੰਦ ਮਾਡਲ ਸਾਂਝੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ: ਪਲੇਟਫਾਰਮ ਟੀਮ ਪੱਕਾ ਰਸਤਾ ਬਣਾਉਂਦੀ ਹੈ; ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਉਸ 'ਤੇ ਚਲਦੀਆਂ ਹਨ ਅਤੇ ਸੁਧਾਰ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰਦੀਆਂ ਹਨ।
IDP ਵੈੱਬ ਐਪ ਦੀ ਸਫਲਤਾ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਕੀ ਇਹ ਸਹੀ ਲੋਕਾਂ ਨੂੰ ਸਹੀ “ਹੈਪੀ ਪਾਥ” ਦਿੰਦਾ ਹੈ। ਕਿੱਸੇ ਟੂਲ ਦੀ ਚੋਣ ਜਾਂ ਆਰਕੀਟੇਕਚਰ ਡਾਇਆਗ੍ਰਾਮ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਕੌਣ ਪੋਰਟਲ ਵਰਤੇਗਾ, ਉਹ ਕੀ ਹਾਸਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਤਰੱਕੀ ਕਿਵੇਂ ਮਾਪੋਗੇ।
ਜ਼ਿਆਦਾਤਰ IDP ਪੋਰਟਲਾਂ ਦੇ ਚਾਰ ਮੁੱਖ ਦਰਸ਼ਕ ਹੁੰਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ ਹਰ ਗਰੁੱਪ ਦੇ ਫਾਇਦੇ ਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਵਰਣਨ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਐਸਾ ਪੋਰਟਲ ਬਣਾ ਰਹੇ ਹੋ ਜੋ ਵਿਕਲਪੀ ਮਹਿਸੂਸ ਹੋਵੇ।
ਉਹ ਯਾਤਰਾਵਾਂ ਚੁਣੋ ਜੋ ਹਫ਼ਤੇ ਵਿੱਚ ਵਾਪਰਦੀਆਂ ਹਨ (ਸਾਲਾਨਾ ਨਹੀਂ) ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਅਸਲ-ਅੰਤ-ਟੂ-ਅੰਤ ਬਣਾਓ:
ਹਰ ਯਾਤਰਾ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖੋ: trigger → steps → systems touched → expected outcome → failure modes. ਇਹ ਤੁਹਾਡਾ ਪ੍ਰੋਡਕਟ ਬੈਕਲੌਗ ਅਤੇ ਸਵੀਕਾਰਤਾ ਮਾਪਦੰਡ ਬਣ ਜਾਵੇਗਾ।
ਚੰਗੇ ਮੈਟ੍ਰਿਕਸ ਸਿੱਧਾ ਸਮਾਂ ਬਚਾਉਣ ਅਤੇ ਰੁਕਾਵਟ ਘਟਾਉਣ ਨਾਲ ਜੁੜੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ:\n\n- ਨਵੀਂ ਸਰਵਿਸ ਲਈ time-to-first-deploy (median, p90)\n- ਆਮ ਬੇਨਤੀਆਂ ਲਈ ਮੈਨੁਅਲ ਟਿਕਟ ਵਾਲੀ ਵਰਤੋਂ (ਅਤੇ ਸਮਾਂ-ਟੂ-ਰਿਜੋਲੂਸ਼ਨ)\n- ਅਡਾਪਸ਼ਨ ਰੇਟ: ਰਜਿਸਟਰ ਕੀਤੀਆਂ ਸਰਵਿਸਾਂ ਦਾ %, ਟੀਮਾਂ ਵੱਲੋਂ ਟੈਮਪਲੇਟ ਯੂਜ਼ ਕਰਨ ਦੀ ਦਰ\n- ਚੇਨਜ ਫੇਲਿਊਰ ਰੇਟ ਅਤੇ mean time to restore (MTTR) (ਜੇ ਪੋਰਟਲ ਡਿਲਿਵਰੀ ਨੂੰ ਮਿਆਰਬੱਧ ਕਰਦਾ ਹੈ)
ਛੋਟਾ ਅਤੇ ਦਿਖਾਈ ਦੇਣਯੋਗ ਰੱਖੋ:
V1 ਸਕੋਪ: “ਇਕ ਪੋਰਟਲ ਜੋ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਟੈਮਪਲੇਟਾਂ ਤੋਂ ਸਰਵਿਸ ਬਣਾਉਣ ਦਿੰਦਾ ਹੈ, ਇਸਨੂੰ ਸਰਵਿਸ ਕੈਟਾਲੌਗ ਵਿੱਚ ਇੱਕ ਮਾਲਕ ਦੇ ਨਾਲ ਰਜਿਸਟਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ + ਹੈਲਥ ਸਥਿਤੀ ਦਿਖਾਉਂਦਾ ਹੈ। ਬੁਨਿਆਦੀ RBAC ਅਤੇ ਆਡਿਟ ਲੌਗ ਸ਼ਾਮਲ ਹਨ। ਵਿਸ਼ੇਸ਼ ਡੈਸ਼ਬੋਰਡ, ਪੂਰੀ CMDB ਬਦਲੀ, ਅਤੇ ਨਿਰਦਿਸ਼ਟ ਵਰਕਫਲੋਜ਼ ਐਕਸਕਲੂਡ ਹਨ।”
ਇਹ ਬਿਆਨ ਤੁਹਾਡਾ ਫੀਚਰ-ਕ੍ਰੀਪ ਫਿਲਟਰ ਅਤੇ ਅਗਲੇ ਰੂਟਮੈਪ ਲਈ ਲੰਗਰ ਹੈ।
ਇਕ ਅੰਦਰੂਨੀ ਪੋਰਟਲ ਤਦ ਹੀ ਸਫਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਇੱਕ ਦਰਦਨਾਕ ਸਮੱਸਿਆ ਨੂੰ ਅੰਤ-ਟੂ-ਅੰਤ ਹੱਲ ਕਰਦਾ ਹੈ, ਫਿਰ ਵਧਣ ਦਾ ਹੱਕ ਕਮਾਉਂਦਾ ਹੈ। ਤੇਜ਼ ਰਸਤਾ ਇੱਕ ਤੰਗ MVP ਹੈ ਜੋ ਅਸਲ ਟੀਮ ਨੂੰ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਭੇਜਿਆ ਜਾ ਸਕੇ—ਕੁਆਰਟਰਾਂ ਨਹੀਂ।
ਤਿੰਨ ਨਿਰਮਾਣ بلاਕਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਇਹ MVP ਛੋਟਾ ਹੈ, ਪਰ ਇੱਕ ਸਪਸ਼ਟ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ: “ਮੈਂ ਆਪਣੀ ਸਰਵਿਸ ਲੱਭ ਸਕਦਾ ਹਾਂ ਅਤੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਕਾਰਵਾਈ ਬਿਨਾਂ Slack 'ਤੇ ਪੁੱਛੇ ਕਰ ਸਕਦਾ ਹਾਂ।”
ਜੇ ਤੁਸੀਂ UX ਅਤੇ ਵਰਕਫਲੋ “ਹੈਪੀ ਪਾਥ” ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai ਵਰਗਾ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ ਲਈ ਲਾਭਕਾਰੀ ਹੋ ਸਕਦਾ ਹੈ। Koder.ai React-ਅਧਾਰਿਤ ਵੈੱਬ ਐਪ, Go + PostgreSQL ਬੈਕਇੰਡ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਸਰੋਤ ਕੋਡ ਐਕਸਪੋਰਟ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਜੋ ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਟ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦਾ ਹੈ ਪਰ ਲੰਬੀ ਅਵਧੀ ਦੀ ਮਲਕੀਅਤ ਵੀ ਰੱਖਦੀ ਹੈ।
ਰੋਡਮੈਪ ਨੂੰ ਸੰਯੋਜਿਤ ਰੱਖਣ ਲਈ ਕੰਮ ਨੂੰ ਚਾਰ ਬਕਟਾਂ ਵਿੱਚ ਗਰੁੱਪ ਕਰੋ:
ਇਹ ਸਰਚਨਾ ਇਕ ਐਸਾ ਪੋਰਟਲ ਰੋਕਦੀ ਹੈ ਜੋ “ਸਿਰਫ ਕੈਟਾਲੌਗ” ਜਾਂ “ਸਿਰਫ ਆਟੋਮੇਸ਼ਨ” ਬਣ ਕੇ ਰਹਿ ਜਾਂਦਾ ਹੈ ਬਿਨਾਂ ਕੁਝ ਜੋੜਨ ਦੇ।
ਸਿਰਫ ਉਹੀ ਚੀਜ਼ਾਂ ਆਟੋਮੇਟ ਕਰੋ ਜੋ ਘੱਟੋ-ਘੱਟ ਇਕ ਸੁਤਰਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦੀਆਂ ਹਨ: (1) ਹਫ਼ਤੇ ਵਿੱਚ ਦੋਹਰਾਈ ਜਾਂਦੀਆਂ ਹਨ, (2) ਹੱਥ ਨਾਲ ਕਰਨ 'ਤੇ ਗਲਤੀਆਂ-ਪ੍ਰਵਣ ਹਨ, (3) ਬਹੁ-ਟੀਮ ਸਹਯੋਗ ਦੀ ਲੋੜ ਹੈ। ਹੋਰ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਲਈ ਸਹੀ ਟੂਲ ਵੱਲ ਇੱਕ ਚੰਗੀ-ਤਰ੍ਹਾਂ ਨਿਰਦੇਸ਼ਿਤ ਲਿੰਕ ਅਤੇ ਮਾਲਕੀ ਦਿਓ।
ਪੋਰਟਲ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਇਨ ਕਰੋ ਕਿ ਨਵੇਂ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਇੱਕ ਸਰਵਿਸ ਜਾਂ ਇਨਵਾਇਰਨਮੈਂਟ ਪੇਜ਼ 'ਤੇ ਹੋਰ “ਕਾਰਵਾਈਆਂ” ਵਜੋਂ ਪਲੱਗ ਇਨ ਕੀਤਾ ਜਾ ਸਕੇ। ਜੇ ਹਰ ਨਵਾਂ ਵਰਕਫਲੋ ਇੱਕ ਨੈਵੀਗੇਸ਼ਨ ਬਦਲਾਅ ਦੀ ਲੋੜ ਪੈਦਾ ਕਰੇ, ਤਾਂ ਅਡਾਪਸ਼ਨ ਰੁਕ ਜਾਵੇਗੀ। ਵਰਕਫਲੋਜ਼ ਨੂੰ ਮੋਡੀਊਲ ਵਜੋਂ ਸੁਲਝਾਓ: ਇਕਸਾਰ ਇਨਪੁੱਟ, ਇਕਸਾਰ ਸਥਿਤੀ, ਇਕਸਾਰ ਇਤਿਹਾਸ— ਤਾਂ ਜੋ ਤੁਸੀਂ ਬਿਨਾਂ ਮਨੁੱਖੀ ਮਾਡਲ ਬਦਲੇ ਹੋਰ ਜੋੜ ਸਕੋ।
ਇੱਕ ਪ੍ਰਯੋਗਸ਼ੀਲ IDP ਪੋਰਟਲ ਆਰਕੀਟੈਕਚਰ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਨੂੰ ਸਧਾਰਨ ਰੱਖਦਾ ਹੈ ਜਦਕਿ ਪਿੱਛੇ-ਪਾਸੇ “ਗੰਦੇ” ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਕੰਮ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਦਾ ਹੈ। ਮਕਸਦ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇੱਕ ਵੈੱਬ ਐਪ ਦੇਣਾ ਹੈ, ਹਾਲਾਂਕਿ ਕਾਰਵਾਈਆਂ ਅਕਸਰ Git, CI/CD, ਕਲਾਊਡ ਅਕਾਊਂਟ, ਟਿਕਟਿੰਗ, ਅਤੇ Kubernetes ਵਿੱਛ ਫੈਲਦੀਆਂ ਹਨ।
ਤਿੰਨ ਆਮ ਪੈਟਰਨ ਹਨ, ਅਤੇ ਸਹੀ ਚੋਣ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਕਿੰਨੀਆਂ ਟੀਮਾਂ ਪੋਰਟਲ ਦਾ ਵਿੱਸਤਾਰ ਕਰਨਗੀਆਂ:
ਘੱਟੋ-ਘੱਟ, ਇਹ ਨਿਰਮਾਣ بلاਕ ਉਮੀਦ ਕਰੋ:
ਸ਼ੁਰੂ ਵਿੱਚ ਫੈਸਲਾ ਕਰੋ ਕਿ ਪੋਰਟਲ “ਕੀ ਮਾਲਕ ਹੈ” ਅਤੇ ਕੀ ਇਹ ਸਿਰਫ ਦਿਖਾਉਂਦਾ ਹੈ:
ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ (ਰੇਟ ਲਿਮਿਟ, ਅਸਥਾਈ ਆਉਟੇਜ, ਆਧਾ-ਕامیابی)। ਇਨ੍ਹਾਂ ਲਈ ਡਿਜ਼ਾਇਨ ਕਰੋ:
ਤੁਹਾਡਾ ਸਰਵਿਸ ਕੈਟਾਲੌਗ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਮੌਜੂਦ ਹੈ, ਕੌਣ ਇਸਦਾ ਮਾਲਕ ਹੈ, ਅਤੇ ਇਹ ਸਿਸਟਮ ਵਿੱਚ ਕਿਵੇਂ ਫਿੱਟ ਬੈਠਦਾ ਹੈ। ਸਪਸ਼ਟ ਡੇਟਾ ਮਾਡਲ “ਰਹੱਸਮਈ ਸਰਵਿਸਾਂ”, ਡੁਪਲੀਕੇਟ ਐਂਟਰੀਜ਼, ਅਤੇ ਟੁੱਟੀਆਂ ਆਟੋਮੇਸ਼ਨਜ਼ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਮੰਨੋ ਪਹਿਲਾਂ ਕਿ “ਸਰਵਿਸ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਲਈ, ਇਹ ਇੱਕ deployable ਯੂਨਿਟ (API, worker, website) ਹੁੰਦਾ ਹੈ ਜਿਸਦੀ ਇਕ lifecycle ਹੁੰਦੀ ਹੈ।
ਘੱਟੋ-ਘੱਟ, ਇਹ ਫੀਲਡ ਮਾਡਲ ਕਰੋ:
ਪੋਰਟਲ ਨੂੰ ਚਲਾਉਣ ਵਾਲੀ ਮੈਟਾਡੇਟਾ ਜੋੜੋ:
ਰਿਸ਼ਤਿਆਂ ਨੂੰ ਫਰਸਟ-ਕਲਾਸ ਟ੍ਰੀਟ ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ ਟੈਕਸਟ ਫੀਲਡ ਵਜੋਂ:
primary_owner_team_id ਨਾਲ additional_owner_team_ids)\n- Services ↔ resources: ਕਲਾਊਡ ਰਿਸੋਰਸ (Kubernetes namespaces, queues, dbs) ਨਾਲ ਜੋੜੋ ਤਾਂ ਜੋ ਕੋਈ ਪੁੱਛ ਸਕੇ “ਇਹ ਸਰਵਿਸ ਕੀ ਵਰਤਦੀ ਹੈ?”\n- Service tiers: ਟੀਅਰ ਨੂੰ ਇੱਕ ਸਟ੍ਰਕਚਰਡ enum ਵਜੋਂ ਸਟੋਰ ਕਰੋ, ਅਤੇ ਨੀਤੀ ਨਾਲ ਜੋੜੋ (ਜਿਵੇਂ tier-0 ਲਈ on-call ਅਤੇ ਆਡਿਟ ਲੌਗ ਲਾਜ਼ਮੀ)ਇਹ ਰਿਲੇਸ਼ਨਲ ਸੰਰਚਨਾ ਪੇਜ਼ ਆਉਟਪੁੱਟਸ ਨੂੰ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ ਜਿਵੇਂ “ਟੀਮ X ਵੱਲੋਂ ਹਰ ਚੀਜ਼” ਜਾਂ “ਇਹ ਡੇਟਾਬੇਸ ਨੂੰ ਛੂਹਣ ਵਾਲੀਆਂ ਸਾਰੀਆਂ ਸਰਵਿਸਾਂ”।
ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਕੈਨੋਨੀਕਲ ID ਚੁਣੋ ਤਾਂ ਕਿ ਆਯਾਤਾਂ ਤੋਂ ਬਾਅਦ ਨਕਲ ਨਾਹ ਹੋਵੇ। ਆਮ ਪੈਟਰਨ:
payments-api) ਜੋ ਯੂਨੀਕ ਹੋਵੇ\n- ਇੱਕ ਅਪਮਾਰਜ UUID ਨਾਲ ਇਕ ਮਨੁੱਖ-ਦੋਸਤ slug\n- ਵਿਕਲਪਕ: repo-ਉਤਪੰਨ ਕੀ (github_org/repo) ਜੇ repos ਸਰਵਿਸਾਂ ਨਾਲ 1:1 ਹੋਣਨਾਮ ਨੀਤੀਆਂ (ਅਨੁਮਤ ਅੱਖਰ, ਯੂਨੀਕਨੈੱਸ, ਰੀਨੇਮ ਨੀਤੀ) ਦਸੋ ਅਤੇ ਬਣਾਉਣ ਸਮੇਂ ਵੈਧਤਾ ਕਰੋ।
ਸਰਵਿਸ ਕੈਟਾਲੌਗ ਤਾਜ਼ਾ ਨਾ ਰਹਿਣ 'ਤੇ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਜਾਂ ਘੱਟੋ-ਘੱਟ ਕੁਝ ਚੁਣੋ ਜਾਂ ਜੋੜੋ:
ਹਰ ਰਿਕਾਰਡ ਲਈ last_seen_at ਅਤੇ data_source ਫੀਲਡ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਤਾਜ਼ਗੀ ਦਿਖਾ ਸਕੋ ਅਤੇ ਗਠਜੋੜ ਦੀ ਜਾਂਚ ਕਰ ਸਕੋ।
ਜੇ ਤੁਹਾਡਾ IDP ਵੈੱਬ ਐਪ ਭਰੋਸੇਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਤਿੰਨ ਗੱਲਾਂ ਦੀ ਲੋੜ ਹੈ ਜੋ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਕੰਮ ਕਰਦੀਆਂ ਹਨ: authentication (ਤੁਸੀਂ ਕੌਣ ਹੋ?), authorization (ਤੁਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹੋ?), ਅਤੇ auditability (ਕੀ ਹੋਇਆ, ਅਤੇ ਕੌਣ ਕੀਤਾ?). ਇਨ੍ਹਾਂ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਸਹੀ ਕਰੋ ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ ਦੁਬਾਰਾ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਨਾ ਪਏ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਪੋਰਟਲ ਨਿਰਮਾਣ ਤੱਕ ਵਧੇ।
ਜ਼ਿਆਦਾਤਰ ਕੰਪਨੀਆਂ ਕੋਲ ਪਹਿਲਾਂ ਹੀ identity infrastructure ਹੁੰਦੀ ਹੈ। ਇਸਦਾ ਉਪਯੋਗ ਕਰੋ।
SSO OIDC ਜਾਂ SAML ਰਾਹੀਂ ਡਿਫਾਲਟ ਸਾਈਨ-ਇਨ ਰਾਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ IdP (Okta, Azure AD, Google Workspace ਆਦਿ) ਤੋਂ ਗਰੁੱਪ ਮੈਂਬਰਸ਼ਿਪ ਖਿੱਚੋ। ਫਿਰ ਗਰੁੱਪਾਂ ਨੂੰ ਪੋਰਟਲ ਦੇ ਰੋਲਾਂ ਅਤੇ ਟੀਮ ਮੈਂਬਰਸ਼ਿਪ ਨਾਲ ਨਕਸ਼ਾ ਕਰੋ।
ਇਸ ਨਾਲ ਓਨਬੋਰਡਿੰਗ ਸਧੀਨ ਹੁੰਦੀ ਹੈ (“ਲੌਗ ਇਨ ਕਰੋ ਅਤੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਸਹੀ ਟੀਮ ਵਿੱਚ ਹੋ”), ਪਾਸਵਰਡ ਸਟੋਰੇਜ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ IT ਗਲੋਬਲ ਨੀਤੀਆਂ ਜਿਵੇਂ MFA ਅਤੇ ਸੈਸ਼ਨ ਟਾਈਮਆਊਟ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ।
ਅਸਪਸ਼ਟ “ਐਡਮਿਨ ਵਿਰੁੱਧ ਹਰ ਕੋਈ” ਮਾਡਲ ਤੋਂ ਬਚੋ। ਇੱਕ ਪ੍ਰਯੋਗਸ਼ੀਲ ਸੈੱਟ ਰੋਲਾਂ ਲਈ ਸ਼ੁਝਾਅ ਹੈ:
ਰੋਲ ਨੂੰ ਛੋਟੇ ਅਤੇ ਸਮਝਣਯੋਗ ਰੱਖੋ। ਬਾਅਦ ਵਿੱਚ ਤੁਸੀਂ ਵਧਾ ਸਕਦੇ ਹੋ, ਪਰ ਇੱਕ ਉਲਝਣ-ਭਰਿਆ ਮਾਡਲ ਅਪਣਾਅ ਘਟਾਉਂਦਾ ਹੈ।
Role-based access control (RBAC) ਲਾਜ਼ਮੀ ਹੈ, ਪਰ ਇਹ ਕਾਫ਼ੀ ਨਹੀਂ। ਤੁਹਾਡੇ ਪੋਰਟਲ ਨੂੰ ਰਿਸੋਰਸ-ਲੇਵਲ ਪਰਮੀਸ਼ਨ ਵੀ ਚਾਹੀਦੇ ਹਨ: ਪਹੁੰਚ ਨੂੰ ਟੀਮ, ਸਰਵਿਸ, ਜਾਂ ਇਨਵਾਇਰਨਮੈਂਟ ਤੱਕ ਸੀਮਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਉਦਾਹਰਨ:
ਇਸਨੂੰ ਇੱਕ ਸਧਾਰਣ ਨੀਤੀ ਪੈਟਰਨ ਨਾਲ ਲਾਗੂ ਕਰੋ: (principal) can (action) on (resource) if (condition). ਟੀਮ/ਸਰਵਿਸ ਸਕੋਪ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਵਧਾਓ।
ਆਡਿਟ ਲੌਗਜ਼ ਨੂੰ ਪਹਿਲੇ ਦਰਜੇ ਦੀ ਸਰਵਿਸ ਸਮਝੋ, ਨਾ ਕਿ ਬੈਕਇੰਡ ਵੇਰਵਾ। ਤੁਹਾਡਾ ਪੋਰਟਲ ਇਹ ਦਰਜ ਕਰੇ:
ਆਡਿਟ ਟਰੇਲ ਸਰਵਿਸ ਪੇਜ਼, ਵਰਕਫਲੋ “History” ਟੈਬ, ਅਤੇ ਕੰਪਲਾਇੰਸ ਲਈ admin ਵਿਉਜ਼ ਤੋਂ ਆਸਾਨੀ ਨਾਲ ਐਕਸੇਸਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਇਹ ਘਟਨਾ ਰਿਵਿਊਜ਼ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ ਹੈ।
ਚੰਗੀ IDP ਪੋਰਟਲ UX ਦਾ ਮਕਸਦ ਸੁੰਦਰ ਦਿਖਣਾ ਨਹੀਂ, ਬਲਕਿ ਕਿਸੇ ਨੂੰ ਸ਼ਿਪ ਕਰਨ ਵੇਲੇ ਰੁਕਾਵਟ ਘਟਾਉਣਾ ਹੈ। ਡਿਵੈਲਪਰ ਤਿੰਨ ਸਵਾਲ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕਣੇ ਚਾਹੀਦੇ ਹਨ: ਕਿ ਮੌਜੂਦ ਹੈ? ਮੈਂ ਕੀ ਬਣਾਉ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ? ਹੁਣ ਕੀ ਧਿਆਨ ਦੀ ਲੋੜ ਹੈ?
ਬੈਕਇੰਡ ਸਿਸਟਮਾਂ ਦੀ ਬਜਾਏ (“Kubernetes,” “Jira,” “Terraform”) ਮੀਨੂਜ਼ ਨੂੰ ਉਨ੍ਹਾਂ ਕੰਮਾਂ ਦੇ ਆਸ-ਪਾਸ ਬਣਾਓ ਜੋ ਡਿਵੈਲਪਰ ਅਸਲ ਵਿੱਚ ਕਰਦੇ ਹਨ:
ਇਹ ਟਾਸਕ-ਅਧਾਰਿਤ ਨੈਵੀਗੇਸ਼ਨ ਨਵੀਂ ਟੀਮਾਂ ਲਈ ਓਨਬੋਰਡਿੰਗ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ: ਨਵੇਂ ਸਾਥੀ ਤੁਹਾਡੇ ਟੂਲਚੇਨ ਬਾਰੇ ਜਾਣਨ ਦੀ ਲੋੜ ਨਹੀਂ ਮਹਿਸੂਸ ਕਰਨਗੇ।
ਹਰ ਸਰਵਿਸ ਪੇਜ਼ 'ਤੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦਿਖਾਓ:
ਇਹ “Who owns this?” ਪੈਨਲ ਉੱਪਰ ਰੱਖੋ, ਟੈਬ ਵਿੱਚ ਸੁੱਟਿਆ ਨਾ ਜਾਵੇ। ਜਦੋਂ ਘਟਨਾ ਹੋਵੇ, ਸਕਿੰਟਾਂ ਦੀ ਕੀਮਤ ਹੁੰਦੀ ਹੈ।
ਤੇਜ਼ ਖੋਜ ਪੋਰਟਲ ਦੀ ਤਾਕਤ ਹੈ। ਉਹ ਫਿਲਟਰ ਸਪੋਰਟ ਕਰੋ ਜੋ ਡਿਵੈਲਪਰ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਵਰਤਦੇ ਹਨ: ਟੀਮ, ਲਾਈਫਸਾਈਕਲ (experimental/production), ਟੀਅਰ, ਭਾਸ਼ਾ, ਪਲੇਟਫਾਰਮ, ਅਤੇ “ਮੇਰੇ ਦੁਆਰਾ ਮਲਕੀਅਤ”। ਸਪੱਸ਼ਟ ਸਥਿਤੀ ਸੂਚਕ (healthy/degraded, SLO at risk, blocked by approval) ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਲਿਸਟ ਨੂੰ ਸਕੈਨ ਕਰਕੇ ਫੈਸਲਾ ਕਰ ਸਕੇ।
ਸੰਸਾਧਨ ਬਣਾਉਂਦੇ ਸਮੇਂ, ਸਿਰਫ਼ ਉਹੀ ਪੁੱਛੋ ਜੋ ਅਸਲ ਵਿੱਚ ਲੋੜੀਦਾ ਹੈ। “ਗੋਲਡਨ ਪਾਥ” ਅਤੇ ਡਿਫ਼ਾਲਟ ਵਰਤੋ ਤਾਂ ਕਿ ਗਲਤੀਆਂ ਘੱਟ ਹੋਣ—ਨਾਮਕਰਨ ਨੀਤੀਆਂ, ਲਾਗਿੰਗ/ਮੇਟਰਿਕਸ hooks, ਅਤੇ ਸਟੈਂਡਰਡ CI ਸੈਟਿੰਗਜ਼ ਪਹਿਲਾਂ ਭਰੀਆਂ ਹੋਣ। ਜੇ ਫੀਲਡ ਵਿਕਲਪਿਕ ਹੈ, ਤਾਂ “Advanced options” ਦੇ ਹੇਠਾਂ ਲੁਕਾਓ ਤਾਂ ਕਿ ਖੁਸ਼ ਰਾਹ ਤੇਜ਼ ਰਹੇ।
ਸੈਲਫ-ਸਰਵਿਸ ਹੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇੱਕ ਅੰਦਰੂਨੀ ਡਿਵੈਲਪਰ ਪਲੇਟਫਾਰਮ ਭਰੋਸਾ ਕਮਾਉਂਦਾ ਹੈ: ਡਿਵੈਲਪਰ ਆਮ ਕਾਰਜਾਂ ਨੂੰ ਟਿਕਟ ਖੋਲ੍ਹੇ ਬਿਨਾਂ ਅੰਤ-ਟੂ-ਅੰਤ ਪੂਰਾ ਕਰ ਸਕਣ, ਪਰ ਪਲੇਟਫਾਰਮ ਟੀਮ ਹੋਰਦੀਆਂ ਨੂੰ ਸੁਰੱਖਿਆ, ਕੰਪਲਾਇੰਸ, ਅਤੇ ਲਾਗਤ ਉੱਤੇ ਕੰਟਰੋਲ ਰੱਖ ਸਕੇ।
ਛੋਟੇ ਸੈੱਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਵੱਧ-ਮੁਸ਼ਕਿਲ ਅਤੇ ਉੱਚ-ਘਣਤਾ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਨਕਸ਼ੇ ਕਰਦੇ ਹਨ। ਆਮ “ਪਹਿਲੇ ਚਾਰ”:
ਇਹ ਵਰਕਫਲੋਜ਼ ਅਧਿਕ ਰਾਏਯਾਦਾਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਤੁਹਾਡੇ ਗੋਲਡਨ ਪਾਥ ਨੂੰ ਦਰਸਾਉਣੇ ਚਾਹੀਦੇ ਹਨ, ਫਿਰ ਵੀ ਨਿਯੰਤਰਤ ਚੋਣਾਂ (ਭਾਸ਼ਾ/runtime, ਖੇਤਰ, ਟੀਅਰ, ਡੇਟਾ ਕਲਾਸੀਫਿਕੇਸ਼ਨ) ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ।
ਹਰ ਵਰਕਫਲੋ ਨੂੰ ਇੱਕ ਪ੍ਰੋਡਕਟ API ਵਜੋਂ ਤੁ treat करो। ਇੱਕ ਸਪਸ਼ਟ ਸੰਝੌਤਾ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ, ਟੈਸਟਯੋਗ, ਅਤੇ ਤੁਹਾਡੇ ਟੂਲਚੇਨ ਨਾਲ ਆਸਾਨੀ ਨਾਲ ਜੋੜਯੋਗ ਬਨਾਉਂਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਸ਼ੀਲ ਸੰਝੌਤਾ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ:
UX 'ਤੇ ਧਿਆਨ ਰੱਖੋ: ਸਿਰਫ ਉਹੀ ਇਨਪੁੱਟ ਦਿਖਾਓ ਜੋ ਡਿਵੈਲਪਰ ਵਾਸਤੇ ਫੈਸਲਾ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਬਾਕੀ ਨੂੰ ਸਰਵਿਸ ਕੈਟਾਲੌਗ ਅਤੇ ਨੀਤੀ ਤੋਂ ਨਿਰਧਾਰਿਤ ਕਰੋ।
ਕੁਝ ਕਾਰਵਾਈਆਂ (ਪ੍ਰੋਡ ਪੁਹੁੰਚ, ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ, ਖਰਚ ਵੱਧਾਉਣ) ਲਈ ਮਨਜ਼ੂਰੀਆਂ ਲਾਜ਼ਮੀ ਹਨ। ਪੋਰਟਲ ਮਨਜ਼ੂਰੀਆਂ ਨੂੰ ਭਵਿੱਖਬਾਣੀਯੋਗ ਬਣਾਏ:
ਅਹੰਕਾਰਪੂਰਕ ਗੱਲ ਇਹ ਹੈ ਕਿ ਮਨਜ਼ੂਰੀਆਂ ਵਰਕਫਲੋ ਇੰਜਣ ਦਾ ਹਿੱਸਾ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਹੱਥ ਨਾਲ ਕੀਤੀਆਂ ਗੱਲ-ਬਾਤ। ਡਿਵੈਲਪਰ ਨੂੰ ਸਥਿਤੀ, ਅਗਲੇ ਕਦਮ, ਅਤੇ ਜਾਂਚ ਦਾ ਕਾਰਨ ਦਿਖਾਈ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।
ਹਰ ਵਰਕਫਲੋ ਰਨ ਇੱਕ ਸਥਾਈ ਰਿਕਾਰਡ ਤਿਆਰ ਕਰੇ:
ਇਹ ਇਤਿਹਾਸ ਤੁਹਾਡਾ “ਕਾਗਜ਼ੀ ਨਿਸ਼ਾਨ” ਅਤੇ ਸਹਾਇਤਾ ਪ੍ਰਣਾਲੀ ਬਣ ਜਾਂਦਾ ਹੈ: ਜਦੋਂ ਕੁਝ ਫੇਲ ਹੋਵੇ, ਡਿਵੈਲਪਰ ਵਿਸਥਾਰ ਦੇਖ ਕੇ ਅਕਸਰ ਬਿਨਾਂ ਟਿਕਟ ਖੋਲ੍ਹੇ ਸਮੱਸਿਆ ਹੱਲ ਕਰ ਲੈਂਦੇ ਹਨ। ਇਹ ਡੇਟਾ ਪਲੇਟਫਾਰਮ ਟੀਮਾਂ ਨੂੰ ਟੈਮਪਲੇਟ ਸੁਧਾਰਨ ਅਤੇ ਰਿਕਰਿੰਗ ਫੇਲਿਓਂ ਨੂੰ ਪਛਾਣਨ ਵਿੱਚ ਵੀ ਮਦਦ ਕਰਦਾ ਹੈ।
ਇੱਕ IDP ਪੋਰਟਲ ਤਾਂ ਹੀ “ਅਸਲੀ” ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਪੜ੍ਹ ਸਕੇ ਅਤੇ ਉਹਨਾਂ ਸਿਸਟਮਾਂ 'ਤੇ ਕਾਰਵਾਈ ਕਰ ਸਕੇ ਜੋ ਡਿਵੈਲਪਰ ਪਹਿਲਾਂ ਹੀ ਵਰਤਦੇ ਹਨ। ਇੰਟਿਗ੍ਰੇਸ਼ਨਜ਼ ਇੱਕ ਕੈਟਾਲੌਗ ਐਂਟਰੀ ਨੂੰ ਕੁਝ ਐਸਾ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਤੁਸੀਂ ਡਿਪਲੋਯ, ਨਿਰੀਖਣ, ਅਤੇ ਸਹਾਇਤਾ ਕਰ ਸਕਦੇ ਹੋ।
ਜ਼ਿਆਦਾਤਰ ਪੋਰਟਲਾਂ ਨੂੰ ਬੁਨਿਆਦੀ ਕਨੈਕਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:
ਕਿਹੜਾ ਡੇਟਾ read-only ਹੈ (ਉਦਾਹਰਣ ਲਈ pipeline status) ਅਤੇ ਕਿਹੜਾ write ਹੈ (Deployment trigger) ਸਪਸ਼ਟ ਰਹਿਣ।
API-ਫਰਸਟ ਇੰਟਿਗ੍ਰੇਸ਼ਨਜ਼ ਸੋਝਾ ਤੇ ਟੈਸਟ ਕਰਨ ਯੋਗ ਹੁੰਦੀਆਂ ਹਨ: ਤੁਸੀਂ auth, schema, ਅਤੇ error handling ਨੂੰ ਵੈਧ ਕਰ ਸਕਦੇ ਹੋ।
ਨਜ਼ਦੀਕੀ-ਰੀਅਲ-ਟਾਈਮ ਇਵੈਂਟਸ ਲਈ webhooks ਵਰਤੋ (PR merged, pipeline finished)। ਜਿਨ੍ਹਾਂ ਸਿਸਟਮਾਂ ਲਈ push events ਨਹੀਂ ਹੁੰਦੇ ਜਾਂ ਜਿਥੇ eventual consistency ਚੱਲਦੀ ਹੈ, ਉਹਨਾਂ ਲਈ scheduled sync ਵਰਤੋ (ਉਦਾਹਰਣ: ਰਾਤੀ-ਆਯਾਤ)।
ਇੱਕ ਪਤਲਾ “ਕਨੈਕਟਰ” ਜਾਂ “ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਸਰਵਿਸ” ਬਣਾਓ ਜੋ ਵੈਂਡਰ-ਖਾਸ ਵੇਰਵਿਆਂ ਨੂੰ ਇੱਕ ਸਥਿਰ ਅੰਦਰੂਨੀ ਕੰਟਰੈਕਟ (ਜਿਵੇਂ Repository, PipelineRun, Cluster) ਵਿੱਚ ਨਾਰਮਲਾਈਜ਼ ਕਰੇ। ਇਹ ਜਦੋਂ ਤੁਸੀਂ ਟੂਲ ਮਾਈਗ੍ਰੇਟ ਕਰੋ ਤਾਂ ਬਦਲਾਵਾਂ ਨੂੰ ਅਲੱਗ ਰੱਖਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੀ UI/API ਸੁਥਰੀ ਰਹਿੰਦੀ ਹੈ।
ਪ੍ਰਯੋਗਸ਼ੀਲ ਪੈਟਰਨ:
/deployments/123)ਹਰ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਲਈ ਇੱਕ ਛੋਟਾ ਰਨਬੁੱਕ ਰੱਖੋ: “ਡਿਗਰੇਡ” ਕਿਵੇਂ ਦਿਖਦਾ ਹੈ, UI ਵਿੱਚ ਕਿਵੇਂ ਦਰਸਾਇਆ ਜਾਵੇ, ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਉਦਾਹਰਣ:
ਇਹ ਦਸਤਾਵੇਜ਼ ਉਤਪਾਦ ਦੇ ਨੇੜੇ (ਉਦਾਹਰਣ /docs/integrations) ਕਰੋ ਤਾਂ ਕਿ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਅਟਕਣ ਨਾ ਪਏ।
ਤੁਹਾਡਾ IDP ਪੋਰਟਲ ਸਿਰਫ UI ਨਹੀਂ; ਇਹ ਇੱਕ ਆਰਕੀਸਟਰੇਸ਼ਨ ਲੇਅਰ ਹੈ ਜੋ CI/CD ਨੌਕਸ, ਕਲਾਊਡ ਰਿਸੋਰਸ, ਸਰਵਿਸ ਕੈਟਾਲੌਗ ਅੱਪਡੇਟ ਅਤੇ ਮਨਜ਼ੂਰੀਆਂ ਨੂੰ ਟਰਿੱਗਰ ਕਰਦਾ ਹੈ। ਨਿਰੀਖਣਯੋਗਤਾ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਵਿਸ਼ਵਾਸ ਨਾਲ ਜਵਾਬ ਦੇਣ ਦੀ ਯੋਗਤਾ ਦਿੰਦੀ: “ਕੀ ਹੋਇਆ?”, “ਕਿੱਥੇ ਫੇਲ ਹੋਇਆ?”, ਅਤੇ “ਅਗਲਾ ਕੰਮ ਕੌਣ ਕਰੇ?”
ਹਰ ਵਰਕਫਲੋ ਰਨ ਨੂੰ ਇੱਕ correlation ID ਨਾਲ Instrument ਕਰੋ ਜੋ ਪੋਰਟਲ UI ਤੋਂ ਬੈਕਇੰਡ APIs, ਮਨਜ਼ੂਰੀ ਚੈਕ, ਅਤੇ ਬਾਹਰੀ ਟੂਲ (Git, CI, ਕਲਾਊਡ, ਟਿਕਟਿੰਗ) ਤੱਕ ਫਾਲੋ ਕਰੇ। request tracing ਸ਼ਾਮਿਲ ਕਰੋ ਤਾਂ ਕਿ ਇੱਕ ਦ੍ਰਿਸ਼ਟੀ ਵਿੱਚ ਪੂਰੇ ਰਾਹ ਅਤੇ ਸਮਾਂ ਦਿਖ ਸਕੇ।
ਟਰੇਸਜ਼ ਨੂੰ ਸੰਰਚਿਤ ਲੌਗਸ (JSON) ਨਾਲ ਪੂਰਕ ਕਰੋ ਜੋ ਸ਼ਾਮਿਲ ਕਰਨ: ਵਰਕਫਲੋ ਨਾਂ, ਰਨ ID, ਸਟੈਪ ਨਾਂ, ਟਾਰਗੇਟ ਸਰਵਿਸ, ਇਨਵਾਇਰਨਮੈਂਟ, actor, ਅਤੇ outcome। ਇਸ ਨਾਲ ਇਹ ਆਸਾਨ ਹੋ ਜਾਵੇਗਾ ਕਿ “ਸਾਰੇ failed deploy-template runs” ਜਾਂ “ਸੇਵਾ X ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੀਆਂ ਹਰ ਚੀਜ਼” ਨੂੰ ਫਿਲਟਰ ਕੀਤਾ ਜਾਵੇ।
ਮੁਢਲੇ ਇੰਫਰਾ ਮੈਟ੍ਰਿਕਸ ਕਾਫ਼ੀ ਨਹੀਂ। ਉਹ ਵਰਕਫਲੋ ਮੈਟ੍ਰਿਕਸ ਸ਼امل ਕਰੋ ਜੋ ਅਸਲ ਨਤੀਜਿਆਂ ਨਾਲ ਜੁੜੇ ਹਨ:
ਪਲੇਟਫਾਰਮ ਟੀਮਾਂ ਲਈ “ਇੱਕ ਨਜ਼ਰ” ਪੇਜ਼ ਦਿਓ:
ਹਰ ਸਥਿਤੀ ਨੂੰ ਡ੍ਰਿਲ-ਡਾਊਨ ਵੇਰਵਾ ਅਤੇ ਉਸ ਰਨ ਲਈ ਨਿਰਧਾਰਤ ਲੌਗ/ਟਰੇਸ ਨਾਲ ਜੋੜੋ।
ਟੁੱਟੇ ਇੰਟਿਗ੍ਰੇਸ਼ਨਜ਼ (ਜਿਵੇਂ ਨਿਰੰਤਰ 401/403), ਅਟਕੇ ਹੋਏ ਮਨਜ਼ੂਰੀ (N ਘੰਟਿਆਂ ਲਈ ਕੋਈ ਕਾਰਵਾਈ ਨਹੀਂ), ਅਤੇ ਸਿੰਕ ਫੇਲਅਰ ਲਈ ਅਲਾਰਮ ਸੈੱਟ ਕਰੋ। ਡੇਟਾ ਰਿਟੇਨਸ਼ਨ ਯੋਜਨਾ ਬਣਾਓ: ਉੱਚ-ਮਾਤਰਾ ਵਾਲੇ ਲੌਗ ਛੋਟੀ ਅਵਧੀ ਲਈ ਰੱਖੋ, ਪਰ ਆਡਿਟ ਇਵੈਂਟ compliance ਅਤੇ ਜਾਂਚਾਂ ਲਈ ਲੰਬਾ ਰੱਖੋ, ਸਪਸ਼ਟ ਐਕਸੇਸ ਕੰਟਰੋਲ ਅਤੇ ਐਕਸਪੋਰਟ ਵਿਕਲਪਾਂ ਦੇ ਨਾਲ।
IDP ਪੋਰਟਲ ਵਿੱਚ ਸੁਰੱਖਿਆ ਸਭ ਤੋਂ ਵਧੀਆ ਤਿੱਖੇ ਨਿਰਦੇਸ਼ਾਂ ਵਜੋਂ ਮਹਿਸੂਸ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਰੁਕਾਵਟਾਂ ਵਜੋਂ। ਲਕਸ਼ ਹੈ ਕਿ ਸੁਰੱਖਿਅਤ ਰਾਹ ਆਸਾਨ ਰਾਹ ਬਣੇ—ਫਿਰ ਵੀ ਟੀਮਾਂ ਨੂੰ ਆਜ਼ਾਦੀ ਦੇ ਕੇ ਸ਼ਿਪ ਕਰਨ ਦਿਓ।
ਜ਼ਿਆਦਾਤਰ ਗਵਰਨੈਂਸ ਉਸ ਸਮੇਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਡਿਵੈਲਪਰ ਕੁਝ ਬੇਨਤੀ ਕਰਦਾ ਹੈ (ਨਵੀਂ ਸਰਵਿਸ, ਰਿਪੋ, ਇਨਵਾਇਰਨਮੈਂਟ, ਜਾਂ ਕਲਾਊਡ ਰਿਸੋਰਸ)। ਹਰ ਫਾਰਮ ਅਤੇ API ਕਾਲ ਨੂੰ ਅਣ-ਭਰੋਸੇਯੋਗ ਸਮਝੋ।
ਕୋਡ ਵਿੱਚ ਨੀਤੀਆਂ ਲਾਗੂ ਕਰੋ, ਦਸਤਾਵੇਜ਼ੀ ਵਿੱਚ ਨਹੀਂ:
ਇਸ ਨਾਲ ਤੁਹਾਡਾ ਸਰਵਿਸ ਕੈਟਾਲੌਗ ਸਾਫ਼ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਆਡੀਟ ਆਸਾਨ ਹੁੰਦੀ ਹੈ।
ਪੋਰਟਲ ਅਕਸਰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ ਕਿੜੇ-ਕ੍ਰੇਡੈਂਸ਼ਲ (CI ਟੋਕਨ, कਲਾਊਡ ਐਕਸੇਸ, API keys)। ਸੀਕ੍ਰੇਟਸ ਨੂੰ ਰੇਡੀਓਧਾਰਿਕ ਸਮਝੋ:
ਆਡਿਟ ਲੌਗ ਇਹ ਦਰਜ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ ਕਿ ਕੌਣ ਕੀ ਕੀਤਾ ਅਤੇ ਕਦੋਂ—ਬਿਨਾਂ ਸੀਕ੍ਰੇਟ ਮੁੱਲਾਂ ਨੂੰ ਕੈਪਚਰ ਕੀਤੇ।
ਯਥਾਰਥਪੂਰਨ ਖਤਰੇ 'ਤੇ ਧਿਆਨ ਦਿਓ:
signed webhook verification, least-privilege roles, ਅਤੇ “read” ਅਤੇ “change” ਓਪਰੇਸ਼ਨਾਂ ਦੇ ਵਿਚਕਾਰ ਸਖ਼ਤ ਵੰਡ ਨਾਲ ਨੁਕਸਾਨ ਘਟਾਓ।
ਪੋਰਟਲ ਕੋਡ ਅਤੇ ਉਤਪੰਨ ਟੈਮਪਲੇਟਾਂ ਲਈ CI ਵਿੱਚ ਸੁਰੱਖਿਆ ਚੈੱਕ ਚਲਾਓ (linting, policy checks, dependency scanning)। ਫਿਰ ਨਿਯਮਤ ਸਮੀਖਿਆ ਸ਼ੈਡਯੂਲ ਕਰੋ:
ਗਵਰਨੈਂਸ ਉਸ ਵੇਲੇ ਸਥਿਰ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਰੋਜ਼ਾਨਾ, ਆਟੋਮੇਟਿਕ, ਅਤੇ ਦਿਖਨਹਾਰ ਹੋ—ਜੋ ਕਿ ਇੱਕ ਇੱਕ-ਥੱਲੇ ਦੀ ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ।
ਜੇ ਟੀਮਾਂ ਪੋਰਟਲ ਵਰਤਦੀਆਂ ਨਹੀਂ, ਤਾਂ ਇਹ ਮੁੱਲ ਨਹੀਂ ਪੈਦਾ ਕਰਦਾ। ਰੋਲਆਊਟ ਨੂੰ ਇੱਕ ਪ੍ਰੋਡਕਟ ਲਾਂਚ ਵਾਂਗ ਰੱਖੋ: ਛੋਟੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖੋ, ਫਿਰ ਸਬੂਤ ਦੇ ਆਧਾਰ ਤੇ ਵਧਾਓ।
1–3 ਪ੍ਰਤੀਨਿਧੀ ਟੀਮਾਂ ਨਾਲ ਪਾਇਲਟ ਕਰੋ ਜੋ ਪ੍ਰੇਰਿਤ ਅਤੇ ਪ੍ਰਤੀਨਿਧੀ ਹਨ (ਇੱਕ “ਗ੍ਰੀਨਫੀਲਡ” ਟੀਮ, ਇੱਕ ਲੈਗੇਸੀ-ਭਾਰੀ ਟੀਮ, ਇੱਕ ਜਿਸਦੇ ਉੱਤੇ ਜ਼ਿਆਦਾ ਕੰਪਲਾਇੰਸ ਲੋੜ ਹੈ)। ਉਹਨਾਂ ਦਾ ਅਸਲ ਕੰਮ ਦੇਖੋ—ਸਰਵਿਸ ਰਜਿਸਟਰ, ਇਨਫਰਾਸਟਰਕਚਰ ਬੇਨਤੀ, ਡਿਪਲੋਏ ਟਰਿੱਗਰ ਕਰਨਾ—ਅਤੇ ਫ਼ੀਡਬੈਕ ਦੇ ਆਧਾਰ ਤੇ ਤੁਰੰਤ friction ਹਟਾਓ। ਲਕਸ਼ ਫੀਚਰ-ਪੂਰਨਤਾ ਨਹੀਂ, ਬਲਕਿ ਇਹ ਸਾਬਤ ਕਰਨਾ ਹੈ ਕਿ ਪੋਰਟਲ ਸਮਾਂ ਬਚਾਉਂਦਾ ਅਤੇ ਗਲਤੀਆਂ ਘਟਾਉਂਦਾ ਹੈ।
ਮਾਈਗ੍ਰੇਸ਼ਨ ਕਦਮ ਸਧਾਰਨ ਸਪ੍ਰਿੰਟ ਵਿੱਚ ਫਿੱਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਉਦਾਹਰਣ:
“Day 2” ਅਪਗਰੇਡ ਸਧਾਰਨ ਰੱਖੋ: ਟੀਮਾਂ ਨੂੰ ਆਹਿਸਤਾ-ਆਹਿਸਤਾ ਮੈਟਾਡੇਟਾ ਜੋੜਨ ਅਤੇ bespoke ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਪੋਰਟਲ ਵਰਕਫਲੋਜ਼ ਨਾਲ ਬਦਲਣ ਦਿਓ।
ਵਰਕਫਲੋਜ਼ ਲਈ ਸੰਖੇਪ ਡੌਕਸ ਲਿਖੋ ਜੋ ਅਹੰਕਾਰਪੂਰਕ ਹਨ: “ਸਰਵਿਸ ਰਜਿਸਟਰ ਕਰੋ”, “ਡੇਟਾਬੇਸ ਬੇਨਤੀ ਕਰੋ”, “ਡਿਪਲੋਏ ਰੋਲਬੈਕ”। ਫਾਰਮ ਫੀਲਡਾਂ ਕੋਲ ਇਨ-ਪ੍ਰੋਡਕਟ ਮਦਦ ਜੋੜੋ, ਅਤੇ ਡੂੰਘੀ ਸਮੱਗਰੀ ਲਈ /docs/portal ਅਤੇ /support ਵੱਲ ਲਿੰਕ ਕਰੋ। ਡੌਕਸ ਨੂੰ ਕੋਡ ਵਾਂਗ ਰੱਖੋ: ਵਰਜ਼ਨ, ਰਿਵਿਊ, ਅਤੇ prune ਕਰੋ।
ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਲਗਾਤਾਰ ਮਲਕੀਅਤ ਦੀ ਯੋਜਨਾ ਬਣਾਓ: ਕਿਸੇ ਨੂੰ ਬੈਕਲੌਗ triage, ਬਾਹਰੀ ਟੂਲਾਂ ਲਈ ਕਨੈਕਟਰ ਅਪਡੇਟ ਰੱਖਣਾ, ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਫੇਲ ਹੋਣ 'ਤੇ ਉਪਭੋਗਤਾਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਹੋਵੇਗਾ। ਪੋਰਟਲ ਘਟਨਾ ਲਈ SLAs ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਕਨੈਕਟਰ ਅਪਡੇਟ ਲਈ ਨਿਯਮਤ ਕੈਡੈਂਸ ਸੈਟ ਕਰੋ, ਅਤੇ ਆਡਿਟ ਲੌਗ ਵੇਖੋ ਤਾਂ ਜੋ ਘਟਨਾਵਾਂ ਅਤੇ ਨੀਤੀ ਖਾਮੀਆਂ ਪਛਾਣੀਆਂ ਜਾ ਸਕਣ।
ਜਿਵੇਂ ਜਿਵੇਂ ਤੁਸੀਂ ਪੋਰਟਲ ਨੂੰ ਮੈਚਰ ਬਣਾਉਂਦੇ ਹੋ, ਤੁਸੀਂ ਸੰਭਵ ਤੌਰ ਤੇ ਉਹ ਸੁਵਿਧਾਵਾਂ ਚਾਹੁੰਦੇ ਹੋਗੇ ਜੋ ਪੋਰਟਲ ਕਨਫਿਗਰੇਸ਼ਨ ਲਈ snapshots/rollback, ਨਿਰਧਾਰਿਤ ਡੀਪਲੋਇਮੈਂਟ, ਅਤੇ ਖੇਤਰਾਂ ਵਿਚਕਾਰ ਆਸਾਨ environment promotion ਵਾਂਗ ਹਨ। ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਿਲਡ ਜਾਂ ਪਰੀਖਣ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ Koder.ai ਟੀਮਾਂ ਨੂੰ internal apps ਖੜੇ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ—planning mode, ਡੀਪਲੋਇਮੈਂਟ/ਹੋਸਟਿੰਗ, ਅਤੇ ਕੋਡ ਐਕਸਪੋਰਟ ਦੇ ਨਾਲ—ਪਰ pilote ਤੋਂ ਬਾਅਦ ਉਨ੍ਹਾਂ ਫੀਚਰਾਂ ਨੂੰ ਲੰਬੀ ਮਿਆਦ ਦੇ ਪਲੇਟਫਾਰਮ ਹਿੱਸਿਆਂ ਵਿੱਚ ਸੁਚੱਜੇ ਢੰਗ ਨਾਲ ਮਜ਼ਬੂਤ ਕਰਨਾ ਬਿਹਤਰ ਰਹੇਗਾ।
ਇੱਕ IDP ਵੈੱਬ ਐਪ ਇੱਕ ਅੰਦਰੂਨੀ ਡਿਵੈਲਪਰ ਪੋਰਟਲ ਹੈ ਜੋ ਤੁਹਾਡੇ ਮੌਜੂਦਾ ਟੂਲ (Git, CI/CD, cloud consoles, ticketing, secrets) ਨੂੰ ਸੰਚਾਲਿਤ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਡਿਵੈਲਪਰ ਇੱਕ ਸਥਿਰ “ਗੋਲਡਨ ਪਾਥ” ਦੀ ਪਾਲਨਾ ਕਰ ਸਕਣ। ਇਸਦਾ ਮਕਸਦ ਉਹਨਾਂ ਤੰਤਰਾਂ ਦੀ ਥਾਂ ਲੈਣਾ ਨਹੀਂ ਜੋ ਸਰੋਤ-ਅਧਾਰ ਹਨ; ਇਹ ਆਮ ਕੰਮਾਂ ਨੂੰ ਖੋਜਯੋਗ, ਮਿਆਰੀਕृत ਅਤੇ ਸੈਲ्फ-ਸਰਵਿਸ ਬਣਾਉਂਦਾ ਹੈ।
ਉਹ ਸਮੱਸਿਆਵਾਂ ਜਿਨ੍ਹਾਂ ਨਾਲ ਹਰ ਹਫ਼ਤੇ ਸਾਮਨਾ ਹੁੰਦਾ ਹੈ ਉਨ੍ਹਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ:
ਜੇ ਪੋਰਟਲ ਕਿਸੇ ਅਮਲ ਨੂੰ ਅਖੀਰ-ਤੱਕ ਤੇਜ਼ ਜਾਂ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਤਾਂ ਇਹ ਵਿਕਲਪੀ ਮਹਿਸੂਸ ਹੋਵੇਗਾ ਅਤੇ اپਣਾਅ ਰੁਕ ਸਕਦਾ ਹੈ।
V1 ਨੂਂ ਛੋਟਾ ਪਰ ਪੂਰਾ ਰੱਖੋ:
ਇਹ ਇਕ حقیقی ਟੀਮ ਨੂੰ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਭੇਜੋ, ਫਿਰ ਵਰਤੋਂ ਅਤੇ ਰੁਕਾਵਟਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਫੈਲਾਓ।
ਯਾਤਰਾਵਾਂ ਨੂਂ ਸਵੀਕਾਰਤਾ ਮਾਪਦੰਡ ਵਾਂਗ ਲਿਖੋ: trigger → steps → systems touched → expected outcome → failure modes. ਚੰਗੀਆਂ ਸ਼ੁਰੂਆਤੀ ਯਾਤਰਾਵਾਂ ਵਿੱਚ ਸ਼ਾਮِل ਹਨ:
ਉਹ ਮੈਟ੍ਰਿਕਸ ਵਰਤੋ ਜੋ ਤਰੱਕੀ ਅਤੇ ਘੱਟ-ਟਕਰਾਅ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ:
ਆਮ ਵੰਡ ਇਹ ਹੈ:
UI 'ਚ ਮਲਕੀਅਤ ਸਪਸ਼ਟ ਦਿਖਾਓ (ਟੀਮ, on-call, ਐਸਕਲੇਸ਼ਨ) ਅਤੇ ਪਰਮੀਸ਼ਨ ਨਾਲ ਬੈਕ ਕਰੋ ਤਾਂ ਕਿ ਸਰਵਿਸ ਮਾਲਕ ਆਪਣੀਆਂ ਐਂਟਰੀਜ਼ ਬਿਨਾਂ ਪਲੇਟਫਾਰਮ ਟੀਮ ਟਿਕਟਾਂ ਦੇ ਸੰਭਾਲ ਸਕਣ।
ਸਰਵਿਸ ਕੈਟਾਲੌਗ ਨੂੰ ਫਰਮਾ-ਅਸਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ:
ਇੱਕ ਕੈਨੋਨੀਕਲ ID (slug + UUID ਆਮ ਹੈ) ਵਰਤੋ ਤਾਂ ਕਿ ਡੁਪਲਿਕੇਟਾਂ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ; ਸੰਬੰਧ ਸਟੋਰ ਕਰੋ (service↔team, service↔resource) ਅਤੇ ਤਾਜਗੀ ਦਰਸਾਉਣ ਲਈ ਅਤੇ ਜਿਹੇ ਫੀਲਡ ਰੱਖੋ।
ਐਂਟਰਪ੍ਰਾਈਜ਼ ਪਛਾਣ ਨਾਲ ਡਿਫਾਲਟ ਕਰੋ:
ਵਰਕਫਲੋ ਇਨਪੁੱਟ (ਸਿਕ੍ਰੇਟਸ redact ਕੀਤੇ ਹੌਣ) ਅਤੇ ਨਤੀਜੇ ਦੀਆਂ ਘਟਨਾਵਾਂ ਲਈ ਆਡਿਟ ਇਵੈਂਟ ਰਿਕਾਰਡ ਕਰੋ ਅਤੇ ਉਹ ਇਤਿਹਾਸ ਸੇਵਾ ਅਤੇ ਵਰਕਫਲੋ ਪੇਜ਼ਾਂ 'ਤੇ ਦਿਖਾਓ ਤਾਂ ਕਿ ਟੀਮਾਂ ਖੁਦ-ਡਿਬੱਗ ਕਰ ਸਕਣ।
ਇੰਟਿਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਮਜ਼ਬੂਤ ਬਣਾਉਣ ਲਈ ਡਿਜ਼ਾਇਨ ਕਰੋ:
ਹਰ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਲਈ ਇੱਕ ਛੋਟਾ ਰਨਬੁੱਕ ਰੱਖੋ (ਉਦਾਹਰਣ ) ਤਾਂ ਕਿ ਵਿਕਾਸਕਾਰੀ ਜਾਣ ਸਕਣ ਕਿ ਬਾਹਰੀ ਸਿਸਟਮ ਡਾਊਨ ਹੋਣ 'ਤੇ ਕੀ ਕਰਨਾ ਹੈ।
ਉਹ ਮੈਟ੍ਰਿਕਸ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਵਰਕਫਲੋ ਰਨਜ਼, ਮਨਜ਼ੂਰੀਆਂ ਅਤੇ ਇੰਟਿਗ੍ਰੇਸ਼ਨਜ਼ ਤੋਂ ਇੰਸਟਰੂਮੈਂਟ ਕਰ ਸਕਦੇ ਹੋ—ਸਰਵੇ ਨਹੀਂ।
last_seen_atdata_source/docs/integrations