01 ਮਾਰਚ 2025·8 ਮਿੰਟ
API ਡੌਕਸ ਅਤੇ ਚੇਂਜਲੋਗ ਲਈ ਵੈੱਬ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ
API ਡੌਕਸ ਅਤੇ ਚੇਂਜਲੋਗ ਨੂੰ ਕੇਂਦਰੀਕ੍ਰਿਤ ਕਰਨ ਵਾਲਾ ਵੈੱਬ ਐਪ ਪਲਾਨ, ਡਿਜ਼ਾਇਨ ਅਤੇ ਬਣਾਉਣ ਦੀ ਰਾਹ-ਦਰਸ਼ਨ: ਵਰਜ਼ਨਿੰਗ, ਅਪ੍ਰੂਵਲ, ਖੋਜ਼ ਅਤੇ ਸੂਚਨਾਵਾਂ ਸਮੇਤ।
API ਡੌਕਸ ਅਤੇ ਚੇਂਜਲੋਗ ਨੂੰ ਕੇਂਦਰੀਕ੍ਰਿਤ ਕਰਨ ਵਾਲਾ ਵੈੱਬ ਐਪ ਪਲਾਨ, ਡਿਜ਼ਾਇਨ ਅਤੇ ਬਣਾਉਣ ਦੀ ਰਾਹ-ਦਰਸ਼ਨ: ਵਰਜ਼ਨਿੰਗ, ਅਪ੍ਰੂਵਲ, ਖੋਜ਼ ਅਤੇ ਸੂਚਨਾਵਾਂ ਸਮੇਤ।
ਕਿਸੇ ਵੀ ਫੀਚਰ ਜਾਂ ਟੈਕਸਟੈਕ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਇਹ ਐਪ ਕਿਸ ਲਈ ਹੈ ਅਤੇ ਕਿਉਂ ਬਣ ਰਹੀ ਹੈ। API ਡੌਕਸ ਅਤੇ ਚੇਂਜਲੋਗ ਤਦ ਹੀ “ਵਧੀਆ” ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਸਹੀ ਲੋਕਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਹੀ ਜਵਾਬ ਮਿਲਣ ਵਿੱਚ ਮਦਦ ਕਰਨ।
ਉਹ ਸਮੂਹਾਂ ਨਾਮ ਲਿਖ ਕੇ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਐਪ ਵਰਤਣਗੇ ਜਾਂ ਇਸ ਨਾਲ ਪ੍ਰਭਾਵਿਤ ਹੋਣਗੇ:
ਜੇ ਤੁਸੀਂ ਸਭ ਲਈ ਇਕੋ-ਇਕੋ ਤਰ੍ਹਾਂ ਵਧੀਆ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋਗੇ, ਤਾਂ ਪਹਿਲਾ ਰਿਲੀਜ਼ ਸੰਭਵਤ: ਗੁੰਝਲਦਾਰ ਹੋਵੇਗਾ। ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਦਰਸ਼ਕ ਚੁਣੋ ਅਤੇ ਹੋਰਾਂ ਨੂੰ ਦੂਜੀਕ੍ਰਮ ਸਮਝੋ।
ਹਾਲੀਆ ਘਟਨਾਵਾਂ ਦੇ ਉਦਾਹਰਣ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਹੱਲ ਕਰ ਰਹੇ ਹੋ:
ਵਿਕੀਜ਼ ਅਤੇ ਰੈਪੋਜ਼ ਵਿੱਚ ਵਿਖਰੇ ਹੋਏ ਡੌਕਸ, Slack ਵਿੱਚ ਪੋਸਟ ਕੀਤੇ ਰਿਲੀਜ਼ ਨੋਟ ਪਰ ਜ਼ਤ ਨਹੀਂ ਰਖੇ ਜਾਂਦੇ, ਐਂਡਪੋਇੰਟ ਬਿਨਾਂ ਸਪੱਠ ਡਿਪਰੀਕੇਸ਼ਨ ਨੀਤੀ ਦੇ ਬਦਲੇ ਹੋ ਜਾਣ, ਇਕाधिक “latest” ਵਰਜ਼ਨ, ਜਾਂ ਸਪੋਰਟ ਟਿਕਟਾਂ ਜੋ ਅਖੀਰਕਾਰ "ਇਹ ਕਿੱਥੇ ਦਸਤਾਵੇਜ਼ ਹੈ?" 'ਤੇ ਆਖਦਾ ਹੈ।
ਇਹਨਾਂ ਨੂੰ ਅਜਿਹੇ ਬਿਆਨਾਂ ਵਿੱਚ ਬਦਲੋ ਜੋ ਤੁਸੀਂ ਜਾਂਚ ਸਕੋ, ਉਦਾਹਰਨ:
ਓਹ ਮੈਟਰਿਕ ਚੁਣੋ ਜੋ ਨਤੀਜਿਆਂ ਨਾਲ ਜੁੜੇ ਹੋਣ:
ਮਾਪਣ ਕਿਵੇਂ ਹੋਵੇਗਾ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (ਐਨਾਲਿਟਿਕਸ, ਟਿਕਟ ਟੈਗ, ਅੰਦਰੂਨੀ ਸਰਵੇ)।
ਕਈ ਟੀਮਾਂ ਨੂੰ ਮਿਕਸਡ ਐਕਸੈਸ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਕੋਰ ਐਂਡਪੋਇੰਟ ਲਈ ਪਬਲਿਕ ਡੌਕਸ, ਪਾਰਟਨਰ-ਖਾਸ ਫੀਚਰਾਂ ਲਈ ਪ੍ਰਾਈਵੇਟ ਡੌਕਸ, ਅਤੇ ਸਪੋਰਟ ਲਈ ਅੰਦਰੂਨੀ ਨੋਟ।
ਜੇ ਤੁਸੀਂ ਮਿਕਸਡ ਐਕਸੈਸ ਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਪਹਿਲੇ ਦਰਜੇ ਦੀ ਲੋੜ ਵਜੋਂ ਸਮਝੋ—ਤੁਹਾਡੀ ਸਮੱਗਰੀ ਬਣਤਰ ਅਤੇ ਪਰਮਿਸ਼ਨ ਮਾਡਲ ਇੱਥੇ ਨਿਰਭਰ ਕਰਨਗੇ।
ਪਹਿਲੀ ਰਿਲੀਜ਼ ਨੂੰ ਕੀ ਹਾਸਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਸਪਸ਼ਟ ਕਰੋ। ਉਦਾਹਰਨ:
“ਸਪੋਰਟ ਇੱਕ ਸਥਿਰ ਲਿੰਕ ਸਾਂਝਾ ਕਰ ਸਕੇ ਜੋ ਵਰਜ਼ਨ ਕੀਤੀ ਡੌਕਸ ਅਤੇ ਮਨੁੱਖ-ਪੜ੍ਹਨਯੋਗ ਚੇਂਜਲੋਗ ਦਿਖਾਵੇ, ਅਤੇ ਪ੍ਰੋਡਕਟ ਟੀਮ ਇੱਕ ਕਾਰੋਬਾਰੀ ਦਿਨ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਸਕੇ।”
ਇਹ ਪਰਿਭਾਸ਼ਾ ਅੱਗਲੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਤੁਹਾਡੇ ਹਰ ਟਰੇਡ-ਉਫ਼ ਨੂੰ ਗਾਈਡ ਕਰੇਗੀ।
API ਡੌਕਿਊਮੈਂਟੇਸ਼ਨ ਐਪ ਦਾ MVP ਇੱਕ ਗੱਲ ਸਾਬਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਤੁਹਾਡੀ ਟੀਮ ਸਹੀ ਡੌਕਸ ਅਤੇ ਚੇਂਜਲੋਗਜ਼ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਪਾਠਕ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹਨ ਕਿ ਕੀ ਬਦਲਿਆ। ਪਹਿਲਾਂ ਉਹ ਫੀਚਰ ਚੁਣੋ ਜੋ ਕੋਰ ਪਬਲਿਸ਼ਿੰਗ ਲੂਪ ਨੂੰ ਸਹਾਇਤਾ ਕਰਦੇ ਹਨ, ਫਿਰ ਹੀ ਉਹ ਸੁਵਿਧਾਵਾਂ ਸ਼ਾਮਲ ਕਰੋ ਜੇ ਉਹ ਸਿੱਧਾ ਰੁਕਾਵਟ ਘਟਾਉਂਦੀਆਂ ਹੋਣ।
ਛੋਟੇ ਸੈੱਟ 'ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਅਸਲ ਡੌਕਿਊਮੈਂਟੇਸ਼ਨ ਅਤੇ ਅਸਲ ਰਿਲੀਜ਼ ਨੂੰ ਸਹਾਰਾ ਦਿੰਦਾ ਹੈ:
Markdown ਆਮ ਤੌਰ 'ਤੇ ਉੱਚ ਗੁਣਵੱਤਾ ਵਾਲੀ ਤਕਨੀਕੀ ਸਮੱਗਰੀ ਲਈ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸੰਪਾਦਕ-ਮਿੱਤਰ ਵੀ ਰਹਿੰਦਾ ਹੈ।
ਆਪਣਾ ਸੰਪਾਦਕ ਇਹ ਸਹਾਇਤਾ ਕਰੇ:
ਇਹ ਕੀਮਤੀ ਹਨ, ਪਰ ਸ਼ੁਰੂ ਵਿੱਚ ਓਵਰਬਿਲਡ ਕਰਨਾ ਆਸਾਨ ਹੈ:
ਹੁਣ ਲਿਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਰੀ-ਆਰਕੀਟੈਕਟ ਨਾ ਕਰਨਾ ਪਵੇ:
ਵੱਡੀਆਂ ਸੰਸਥਾਵਾਂ ਨੂੰ ਵੇਚਣ ਲਈ, ਯੋਜਨਾ ਬਣਾਓ:
ਜੇ ਤੁਸੀਂ ਆਸ਼ੰਕਿਤ ਹੋ, ਤਾਂ ਆਡਿਟ ਲੋਗਿੰਗ ਨੂੰ "ਛੋਟਾ ਹੁਣ, ਜਰੂਰੀ ਬਾਅਦ ਵਿੱਚ" ਸਮਝੋ।
ਸਾਫ਼ ਆਰਕੀਟੈਕਚਰ ਬਾਕੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਅਸਾਨ ਬਣਾਂਦਾ ਹੈ: ਡੌਕਸ ਸੰਪਾਦਨ, ਰਿਲੀਜ਼ ਪ੍ਰਕਾਸ਼ਨ, ਖੋਜ਼, ਅਤੇ ਸੂਚਨਾਵਾਂ ਭੇਜਣਾ। API ਡੌਕਸ + ਚੇਂਜਲੋਗ ਐਪ ਲਈ, ਪਹਿਲਾ ਵਰਜਨ ਸਧਾਰਨ ਰੱਖੋ ਪਰ ਵਧਣ ਦੀ ਜਗ੍ਹਾ ਛੱਡੋ।
ਚਾਰ ਬਿਲਡਿੰਗ ਬਲੌਕ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਇਹ ਵੱਖ-ਵੱਖ ਭਾਗਾਂ ਦੀ ਵੱਖਰੀ ਸਕੇਲਿੰਗ ਦਿੰਦਾ ਹੈ: ਭਾਰੀ ਖੋਜ਼ ਜਾਂ ਰੈਂਡਰਿੰਗ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਸੰਪਾਦਕ ਨੂੰ ਧਿਮਾ ਨੀ ਕਰੇਗੀ।
ਕਈ ਚੰਗੇ ਵਿਕਲਪ ਹਨ; ਸਭ ਤੋਂ ਵਧੀਆ ਚੋਣ ਅਕਸਰ ਉਹ ਹੈ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਭਰੋਸੇ ਨਾਲ ਸ਼ਿਪ ਅਤੇ ਰੱਖ ਸਕੇ।
ਫਰੰਟਐਂਡ ਲਈ ਆਮ ਚੋਣ React/Next.js ਹੈ ਜਿਹੜਾ SEO-ਮਿੱਤਰ ਡੌਕਸ ਪੇਜ ਅਤੇ ਮੁਸਲਾਹਤ ਭਰਪੂਰ ਐਡੀਟਰ ਅਨਭਵ ਮੁਹੱਈਆ ਕਰਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡੇ ਲੱਖੇ ਦਾ ਮੁੱਖ ਮਕਸਦ ਤੇਜ਼ੀ ਨਾਲ ਵਰਕਿੰਗ ਪੋਰਟਲ ਖੜਾ ਕਰਨਾ ਹੈ, ਤਾਂ Koder.ai ਵਰਗਾ ਪਲੇਟਫਾਰਮ ਇੱਕ ਪ੍ਰਯੋਗਕਾਰੀ ਤੇਜ਼ੀ-ਵਾਲਾ ਵਿਕਲਪ ਹੋ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਚੈਟ ਵਿੱਚ ਡੌਕਸ ਵਰਕਫਲੋ ਅਤੇ ਪਰਮਿਸ਼ਨ ਨਿਯਮ ਵਰਣਨ ਕਰਕੇ React ਫਰੰਟਐਂਡ, Go ਬੈਕਐਂਡ (PostgreSQL) ਜਨਰੇਟ ਕਰਵਾ ਸਕਦੇ ਹੋ ਅਤੇ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਵੇਰਵਿਆਂ 'ਤੇ ਕੰਮ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ “ਪਲਾਨਿੰਗ ਮੋਡ” ਵਿੱਚ ਇਤਰੈਟ ਕਰ ਸਕਦੇ ਹੋ।
ਇਹ ਫੈਸਲਾ ਜਲਦੀ ਕਰੋ ਕਿਉਂਕਿ ਇਹ ਬਾਅਦ ਵਿੱਚ ਵਰਜ਼ਨਿੰਗ ਅਤੇ ਵਰਕਫਲੋ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦਾ ਹੈ:
ਸ਼ੁਰੂ ਤੋਂ ਹੀ local → staging → production ਯੋਜਨਾ ਬਣਾਓ, ਭਾਵੇਂ ਸਟੇਜਿੰਗ ਘੱਟੋ-ਘੱਟ ਹੋਵੇ। ਸੰਭਵ ਇੰਟੀਗ੍ਰੇਸ਼ਨ (CI ਵੈਰੀਫਾਈ ਕਰਨ ਲਈ, ਅਪ੍ਰੂਵਲ ਲਈ ਟਿਕਟਿੰਗ, ਰਿਲੀਜ਼ ਸੂਚਨਾ ਲਈ ਚੈਟ) ਦੀ ਇੱਕ ਸੂਚੀ ਵੀ ਤਿਆਰ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਐਸੇ ਚੋਣ ਨਾ ਕਰੋ ਜੋ ਬਾਅਦ ਵਿੱਚ ਰੋਡਬਲੌਕ ਬਣ ਜਾਂ।
ਸਾਫ਼ ਡੇਟਾ ਮਾਡਲ ਉਸ ਗੱਲ ਨੂੰ ਬਣਾ ਦਿੰਦਾ ਹੈ ਜੋ ਬਾਅਦ ਵਿੱਚ ਤੁਹਾਡੇ ਡੌਕਸ, ਚੇਂਜਲੋਗ ਅਤੇ ਪਰਮਿਸ਼ਨਾਂ ਨੂੰ "ਸਪਸ਼ਟ" ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਸਕੀਮਾ ਰੱਖੋ ਜੋ ਕਈ ਪ੍ਰੋਡਕਟ/API, ਪਬਲਿਸ਼ਿੰਗ ਸਟੇਟ ਅਤੇ ਟ੍ਰੇਸਬਿਲਿਟੀ ਨੂੰ ਸਹਾਰਾ ਦੇਵੇ।
ਅਧਿਕਤਮ API ਡੌਕਿਊਮੈਂਟੇਸ਼ਨ ਐਪ ਹੇਠਾਂ ਦਿੱਤੇ ਬਿਲਡਿੰਗ ਬਲੌਕ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਨ:
ਕੰਟੈਂਟ ਐਸਾ ਮਾਡਲ ਕਰੋ ਕਿ ਆਮ ਪ੍ਰਸ਼ਨਾਂ ਦੇ ਜਵਾਬ ਆਸਾਨ ਹੋਣ:
DocPages ਆਮ ਤੌਰ 'ਤੇ ਹਾਇਰਾਰਕੀ ਦੀ ਲੋੜ ਰੱਖਦੇ ਹਨ। ਇੱਕ ਸਰਲ ਰਵਾਹ parent_id (ਟ੍ਰੀ) ਅਤੇ position ਫੀਲਡ ਹੈ। ਜੇ ਤੁਸੀਂ ਵੱਡੀ ਟਰੀਆਂ ਅਤੇ ਅਕਸਰ ਰੀ-ਆਰਡਰ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹੋ, ਤਾਂ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਇੱਕ ਵੱਖਰਾ ਆਰਡਰਿੰਗ ਰਣਨੀਤੀ (ਜਿਵੇਂ sortable lists) 'ਤੇ ਵਿਚਾਰ ਕਰੋ।
ਹਰ DocPage ਅਤੇ ChangelogEntry ਲਈ ਇਹ ਸਟੋਰ ਕਰੋ:
draft / in_review / publishedਜ਼ਿੰਮੇਵਾਰੀ ਟਰੈਕ ਕਰਨ ਲਈ ਆਡਿਟ ਲੋਗ ਰੱਖੋ: actor_id, action, entity_type, entity_id, before, after, created_at।
ਅਟੈਚਮੈਂਟ ਲਈ object storage (S3/GCS/Azure Blob) ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਅਤੇ DB ਵਿੱਚ ਸਿਰਫ਼ ਮੈਟਾਡੇਟਾ (URL, mime type, size, checksum) ਰੱਖੋ। ਵੱਡੀਆਂ ਬਾਈਨਰੀਜ਼ ਨੂੰ ਡੇਟਾਬੇਸ ਤੋਂ ਬਾਹਰ ਰੱਖਣਾ ਆਮ ਤੌਰ 'ਤੇ ਪਰਫਾਰਮੈਂਸ ਵਧਾਉਂਦਾ ਹੈ ਅਤੇ ਬੈਕਅੱਪ ਨੂੰ ਸਧਾਰਨ ਬਣਾਉਂਦਾ ਹੈ।
ਆਥੈਂਟੀਕੇਸ਼ਨ ਅਤੇ ਅਥਰਾਈਜ਼ੇਸ਼ਨ ਇਹ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਆਪਣੇ ਡੌਕਸ ਅਤੇ ਚੇਂਜਲੋਗਜ਼ ਨੂੰ ਕਿੰਨੇ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਪ੍ਰਬੰਧਿਤ ਕਰ ਸਕਦੇ ਹੋ। ਸ਼ੁਰੂ ਵਿੱਚ ਇਹ ਸਹੀ ਕਰ ਲਓ ਤਾਂ ਕਿ ਤੁਸੀਂ ਸਮੱਗਰੀ ਅਤੇ ਟੀਮਜ਼ ਵਧਣ 'ਤੇ ਨਿਯਮਾਂ ਨੂੰ ਫਿਰੋਂ ਨਹੀਂ ਜੋੜਣਾ ਪਵੇ।
ਛੋਟੇ, ਸਪਸ਼ਟ ਰੋਲ ਸਮੂਹ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਪਰਮਿਸ਼ਨਾਂ ਨੂੰ ਕਾਰਵਾਈ-ਅਧਾਰਤ (create/edit/approve/publish/archive) ਰੱਖੋ ਨਾ ਕਿ ਕੇਵਲ UI ਸਕ੍ਰੀਨ-ਅਧਾਰਿਤ। ਇਹ ਤੁਹਾਡੇ ਨਿਯਮਾਂ ਨੂੰ ਆਡਿਟ ਅਤੇ ਟੈਸਟ ਕਰਨਯੋਗ ਬਨਾਉਂਦਾ ਹੈ।
ਆਮ ਵਿਕਲਪ:
ਜੇ ਤੁਹਾਡੀ ਐਪ ਕਈ ਕੰਪਨੀਆਂ ਦੁਆਰਾ ਵਰਤੀ ਜਾਏਗੀ, ਤਾਂ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਆਰਗਨਾਈਜ਼ੇਸ਼ਨ/ਵਰਕਸਪੇਸ ਮੈਂਬਰਸ਼ਿਪ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ।
ਡੌਕ ਸਿਸਟਮ ਅਕਸਰ ਉਸ ਵੇਲੇ ਫੇਲ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਪੁਰਾਣੀਆਂ ਵਰਜ਼ਨਾਂ ਨੂੰ ਚੁੱਪਚਾਪ ਦੁਬਾਰਾ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਸਪਸ਼ਟ ਨਿਯਮ ਜ਼ਰੂਰੀ ਹਨ, ਉਦਾਹਰਨ:
ਇਹ ਨਿਯਮ API ਪੱਧਰ 'ਤੇ ਮਾਡਲ ਕਰੋ, ਸਿਰਫ਼ ਫਰੰਟਐਂਡ 'ਤੇ ਨਹੀਂ।
ਸੈਸ਼ਨਾਂ ਨੂੰ secure, httpOnly cookies, ਛੋਟੀ ਅਵਧੀ ਵਾਲੇ ਟੋਕੇਨ, ਅਤੇ ਯਥਾਰਥ ਲਾਗਆਊਟ ਨਾਲ ਸੁਰੱਖਿਅਤ ਕਰੋ। cookie-ਅਧਾਰਤ ਸੈਸ਼ਨਾਂ ਲਈ CSRF ਪ੍ਰੋਟੈਕਸ਼ਨ ਜ਼ਰੂਰੀ ਹੈ। ਲੌਗਿਨ, ਪਾਸਵਰਡ ਰੀਸੈੱਟ, ਅਤੇ ਪਬਲਿਸ਼ ਐਂਡਪੋਇੰਟਾਂ 'ਤੇ ਰੇਟ ਲਿਮਿਟਿੰਗ ਲਗਾਓ।
ਅਖੀਰਕਾਰ, ਡੌਕਿਊਮੈਂਟੇਸ਼ਨ ਨੂੰ ਅਣ-ਟ੍ਰਸਟਡ ਇਨਪੁਟ ਵਜੋਂ ਲਓ। HTML/Markdown ਆਉਟਪੁੱਟ ਸੈਨੇਟਾਈਜ਼ ਕਰੋ ਅਤੇ ਸਕ੍ਰਿਪਟ ਇੰਜੈਕਸ਼ਨ (XSS) ਰੋਕੋ। ਜੇ ਤੁਸੀਂ embeds ਸਹਾਇਤਾ ਕਰਦੇ ਹੋ, ਤਾਂ allowlist ਅਤੇ ਸੁਰੱਖਿਅਤ ਰੇਂਡਰਿੰਗ ਡਿਫਾਲਟ ਵਰਤੋ।
ਇੱਕ ਡੌਕ ਪਲੇਟਫਾਰਮ ਉਸਦਾ ਸੰਪਾਦਕ ਹੋਣ ਦੇ ਨਾਲ ਜਿਉਂਦਾ ਜਾਂ ਮਰਦਾ ਹੈ। ਤੁਹਾਡਾ ਲਕਸ਼ ਹੈ ਲਿਖਣਾ ਤੇਜ਼, ਭਰੋਸੇਯੋਗ ਅਤੇ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਕਰਵਾਉਣਾ—ਲੇਖਕਾਂ ਨੂੰ ਇਹ ਭਰੋਸਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਜੋ ਉਹ ਸੰਪਾਦਨ ਵੇਖ ਰਹੇ ਹਨ, ਉਹ ਪਾਠਕਾਂ ਨੂੰ ਵੀ ਉਹੀ ਮਿਲੇਗਾ।
ਜ਼ਿਆਦਾਤਰ API ਟੀਮਾਂ ਨੂੰ Markdown-first ਸੰਪਾਦਨ ਤੋਂ ਫਾਇਦਾ ਹੁੰਦਾ ਹੈ: ਇਹ ਤੇਜ਼, diff-ਮਿੱਤਰ, ਅਤੇ ਵਰਜ਼ਨਿੰਗ ਲਈ ਚੰਗਾ ਹੈ। ਫਿਰ ਵੀ, ਕੁਝ ਯੋਗਦਾਨਕ ਚਾਹੁੰਦੇ ਹਨ ਰਿਚ-ਟੈਕਸਟ ਸਹੂਲਤਾਂ (ਟੇਬਲ, কলਆਊਟ) ਲਈ।
ਵਿਆਵਹਾਰਿਕ ਰਸਤਾ ਦੋ-ਮੋਡ ਹੈ:
ਇੱਕ ਲਾਈਵ ਪ੍ਰੀਵਿਊ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਪੇਜ ਨੂੰ ਉਨ੍ਹਾਂ ਹੀ ਕੰਪੋਨੈਂਟਾਂ, ਫੋਂਟਾਂ ਅਤੇ ਅੰਤਰਾਲ ਨਾਲ ਰੈਂਡਰ ਕਰਦਾ ਹੈ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। "Preview as reader" ਟੌਗਲ ਦਿਓ ਜੋ ਸੰਪਾਦਕ-ਕੇਵਲ UI ਨੂੰ ਛੁਪਾਉਂਦਾ ਹੈ ਅਤੇ ਨੈਵੀਗੇਸ਼ਨ ਅਤੇ ਸਾਈਡਬਾਰ ਦਿਖਾਉਂਦਾ ਹੈ।
ਪ੍ਰੀਵਿਊ ਇਹਨਾਂ ਚੀਜ਼ਾਂ ਲਈ ਸਹੀ ਹੋਵੇ:
ਜਦੋ ਹਰ ਕੋਈ ਇੱਕੋ ਜਿਹੇ ਪੈਟਰਨ ਹੱਥ-ਲਿਖਦਾ ਹੈ ਤਾਂ ਡੌਕਸ ਅਸਮੰਜਸ ਹੋ ਜਾਂਦੇ ਹਨ। ਲੇਖਕਾਂ ਨੂੰ ਇੰਜੈਕਟ ਕਰਨ ਲਈ ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ ਕੰਪੋਨੈਂਟ ਪ੍ਰਦਾਨ ਕਰੋ:
ਇਸ ਨਾਲ ਫਾਰਮੈਟਿੰਗ ਗਲਤੀਆਂ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਅਪਡੇਟ ਸੈੰਟਰਲਾਈਜ਼ ਰਹਿੰਦੇ ਹਨ।
ਆਪਸੀ ਲਿੰਕ ਆਸਾਨ ਅਤੇ ਭਰੋਸੇਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ ਐਂਕਰਾਂ ਨੂੰ ਸਹਾਇਤਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਇਕਸਾਰ ਢੰਗ ਨਾਲ ਜਨਰੇਟ ਕਰੋ ਤਾਂ ਕਿ ਹੇਡਿੰਗਾਂ ਅਚਾਨਕ ਹਿਲਣ ਨਾ।
ਸੰਪਾਦਕ ਤੋਂ ਪਹੁੰਚਯੋਗ ਇੱਕ ਛੋਟਾ ਸਟਾਈਲ ਗਾਈਡ ਸ਼ਾਮਲ ਕਰੋ (ਜਿਵੇਂ /docs/style-guide) ਜਿਸ ਵਿੱਚ:
ਚੋਟੀ-ਦਰਜੇ ਦੇ ਨਿਯਮ ਛੋਟੇ ਹਨ ਪਰ ਬਾਅਦ ਵਿੱਚ ਵੱਡੇ ਸਫਾਈ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਰੋਕਦੇ ਹਨ।
ਵਰਜ਼ਨਿੰਗ ਉਸ ਬਿੰਦੂ ਤੇ ਹੈ ਜਦੋਂ API ਡੌਕਸ "ਕੁਝ ਪੰਨਿਆਂ ਦਾ ਸਮੂਹ" ਨਹੀਂ ਰਹਿ ਕੇ ਇੱਕ ਭਰੋਸੇਯੋਗ ਅਨੁਬੰਧ ਬਣ ਜਾਂਦੇ ਹਨ। ਤੁਹਾਡੀ ਐਪ ਇਹ ਸਪਸ਼ਟ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਕੀ ਰਹਿੰਦਾ ਹੈ ਅਪ-ਟੂ-ਡੇਟ, ਕੀ ਬਦਲਿਆ ਹੈ, ਅਤੇ ਕੀ ਹੁਣ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਰਹਿ ਗਿਆ।
ਦੋ ਆਮ ਪਹਿਰੇ ਕੰਮੂੰ:
ਜੇ ਤੁਹਾਡੇ API ਨੂੰ ਇੱਕ ਇਕਾਈ ਵਜੋਂ ਵਰਜ਼ਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ snapshots ਅਕਸਰ ਘੱਟ ਗੜਬੜ ਕਰਦੇ ਹਨ। ਜੇ ਟੀਮਾਂ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਬਦਲਾਅ ਪਹੁੰਚਾ ਰਹੀਆਂ ਹਨ, ਤਾਂ per-page ਵਰਜ਼ਨਿੰਗ ਜ਼ਿਆਦਾ ਪ੍ਰਯੋਗਿਕ ਹੋ ਸਕਦੀ ਹੈ।
ਦੋ ਬ੍ਰਾਊਜ਼ਿੰਗ ਸ਼ੈਲਜ਼ ਸਹਾਇਤਾ ਕਰੋ:
/docs/latest/... ਆਮ ਪਾਠਕਾਂ ਲਈ।/docs/v1/..., /docs/v1.4/... ਗਾਹਕਾਂ ਲਈ ਜੋ ਸਥਿਰਤਾ ਚਾਹੁੰਦੇ ਹਨ।“latest” ਨੂੰ ਇੱਕ ਪੁਆਇੰਟਰ ਬਣਾਓ, ਨਕਲ ਨਹੀਂ। ਇਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਅਪਡੇਟ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ pinned ਲਿੰਕਾਂ ਨੂੰ ਭੰਗ ਕੀਤੇ।
ਐਪ ਵਿੱਚ ਸਪਸ਼ਟ ਨਿਯਮ ਲਿਖੋ ਤਾਂ ਕਿ ਲੇਖਕ ਅਨੁਮਾਨ ਨਾ ਲਗਾਏ:
ਪਬਲਿਸ਼ਿੰਗ ਦੌਰਾਨ ਇੱਕ ਸਧਾਰਨ ਪ੍ਰਾਰੰਭ ਪੇਸ਼ ਕਰੋ: “ਕੀ ਇਹ breaking ਹੈ?” ਅਤੇ ਇੱਕ ਜ਼ਰੂਰੀ ਵਜੀਹਤ ਲਿਖਣੀ ਲਾਭਦਾਇਕ ਹੈ।
ਡਿਪਰੀਕੇਸ਼ਨ ਨੂੰ ਕੇਵਲ ਚੇਤਾਵਨੀ ਨਹੀਂ ਚਾਹੀਦੀ; ਇਸਨੂੰ ਸਰਚ ਤੇ ਦਿੱਖ ਹੋਣ ਚਾਹੀਦੀ ਹੈ।
ਕੁਝ ਪਹਿਲ-ਕਤਾਰ ਫੀਲਡ ਸ਼ਾਮਲ ਕਰੋ:
ਪ੍ਰਭਾਵਿਤ ਪੰਨਿਆਂ 'ਤੇ ਇੱਕ ਬੈਨਰ ਦਿਖਾਓ ਅਤੇ ਚੇਂਜਲੋਗ ਅਤੇ ਰਿਲੀਜ਼ ਨੋਟਾਂ ਵਿੱਚ ਡਿਪਰੀਕੇਸ਼ਨ ਨੂੰ ਉਭਾਰੋ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਯੋਜਨਾ ਬਣਾ ਸਕਣ।
ਮਾਈਗਰੇਸ਼ਨ ਨੂੰ ਇਤਿਹਾਸ ਆਯਾਤ ਕਰਨ ਵਜੋਂ ਲਓ:
ਇਸ ਨਾਲ ਤੁਸੀਂ ਪਹਿਲੇ ਦਿਨ ਤੇ ਵਰਜ਼ਨਿੰਗ ਯੋਗਜ਼ਾ ਹਾਸਲ ਕਰ ਲਵੋਗੇ ਬਿਨਾਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੇ।
ਇੱਕ ਸਪਸ਼ਟ ਵਰਕਫਲੋ ਟੁੱਟੇ ਹੋਏ ਡੌਕਸ, ਗਲਤ ਰਿਲੀਜ਼ਾਂ, ਅਤੇ “ਇਹ ਕਿਨੇ ਨੇ ਬਦਲਿਆ?” ਵਾਲੀ ਗੁੰਝਲ ਨੂੰ ਰੋਕਦਾ ਹੈ। ਡੌਕ ਪੇਜਾਂ ਅਤੇ ਚੇਂਜਲੋਗ ਐਂਟਰੀਜ਼ ਨੂੰ ਉਹ ਸਮੱਗਰੀ ਮਾਨੋ ਜੋ ਨਿਯਮਤ ਰਾਜਾਂ ਤੋਂ ਗੁਜ਼ਰਦੀ ਹੈ, ਹਰ ਪੜਾਅ 'ਤੇ ਜ਼ਿੰਮੇਵਾਰੀ ਦਿਖਾਉ।
ਇੱਕ ਸਧਾਰਣ state machine ਦਿਓ ਜੋ ਹਰ ਕੋਈ ਸਮਝ ਸਕੇ: draft → in review → approved → published।
ਸਮੀਖਿਆ ਤੇਜ਼ ਅਤੇ ਨਿਰਦਿਸ਼ਟ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਸ਼ਾਮਲ ਕਰੋ:
ਇੰਟਰਫੇਸ ਹਲਕਾ ਰੱਖੋ: ਇੱਕ ਰਿਵਿਊਅਰ ਨੂੰ ਮਿੰਟਾਂ ਵਿੱਚ ਮਨਜ਼ੂਰੀ ਦੇਣ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ, ਕਿਸੇ ਹੋਰ ਜਗ੍ਹਾ 'ਤੇ ਟਿਕਟ ਖੋਲ੍ਹਣ ਦੀ ਲੋੜ ਨਾ ਹੋਵੇ।
ਪਬਲਿਕ ਪੇਜਾਂ ਅਤੇ ਰਿਲੀਜ਼ਾਂ ਲਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਰਿਵਿਊਅਰ (ਜਾਂ “Docs Maintainer” ਵਰਗਾ ਰੋਲ) ਲਾਜ਼ਮੀ ਕਰੋ। ਗੇਟ ਨਿਯਮ ਨੂੰ ਟੀਮ/ਸਪੇਸ ਅਨੁਸਾਰ ਕਨਫਿਗਰ ਕਰਨਯੋਗ ਰੱਖੋ ਤਾਂ ਕਿ ਅੰਦਰੂਨੀ ਡੌਕਸ ਲਈ ਘੱਟ ਕੜਕ ਵਰਕਫਲੋ ਹੋ ਸਕੇ।
ਲੇਖਕਾਂ ਨੂੰ Publish now ਜਾਂ ਇੱਕ ਨਿਰਧਾਰਤ ਤਾਰੀਖ/ਸਮਾਂ (ਟਾਈਮਜ਼ੋਨ ਸਮੇਤ) ਚੁਣਨ ਦਿਓ। ਰੋਲਬੈਕ ਲਈ, ਪਿਛਲੇ published ਵਰਜ਼ਨ ਨੂੰ ਇੱਕ ਕਲਿੱਕ ਵਿੱਚ ਰੀਸਟੋਰ ਕਰਨ ਦੀ ਸੁਵਿਧਾ ਦਿਓ—ਖਾਸ ਕਰਕੇ ਚੇਂਜਲੋਗ ਐਂਟਰੀਜ਼ ਜੋ ਕਿਸੇ ਰਿਲੀਜ਼ ਨਾਲ ਜੁੜੀਆਂ ਹੋਣ।
ਰੀਸਟੋਰ ਨਾਲ ਇੱਕ ਆਡਿਟ ਨੋਟ ਜੋੜੋ ਤਾਂ ਟੀਮ ਜਾਣ ਸਕੇ ਕਿ ਕਿਉਂ ਕੀਤਾ ਗਿਆ।
ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਇਹ ਤਿਆਰ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਪਲੇਟਫਾਰਮ ਦੀ ਆਪਣੀ ਸੁਰੱਖਿਆ ਪਧਤੀ ਨੂੰ ਦੁਰਹਾਊ: ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਬਿਨਾਂ ਡਰ ਦੇ ਲਈ ਇੱਕ ਸਾਬਤ UX ਪੈਟਰਨ ਹਨ, ਅਤੇ ਉਹੀ ਆਈਡੀਅਾ ਡੌਕਸ ਪ੍ਰਕਾਸ਼ਨ 'ਤੇ ਵੀ ਵਧੀਆ ਬੈਠਦੀ ਹੈ।
ਚੇਂਜਲੋਗ ਕੇਵਲ ਉਪਯੋਗੀ ਹੈ ਜੇ ਲੋਕ ਤੇਜ਼ੀ ਨਾਲ ਦੋ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਪਾ ਸਕਣ: ਕੀ ਬਦਲਿਆ ਅਤੇ ਕੀ ਇਹ ਮੇ ਤੇ ਅਸਰ ਕਰਦਾ। ਸਭ ਤੋਂ ਵਧੀਆ ਸਿਸਟਮ ਇੱਕਸਾਰ ਸਰਾਂਚਾ ਲਾਦਦੇ ਹਨ, ਬਦਲਾਵਾਂ ਨੂੰ ਡੌਕਸ ਨਾਲ ਜੋੜਦੇ ਹਨ, ਅਤੇ ਅਪਡੇਟ ਸਵੱਧਿਕਤ ਤਰੀਕਿਆਂ ਨਾਲ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ।
ਐਂਟਰੀਜ਼ ਨੂੰ ਸਕੈਨ ਕਰਨ ਲਈ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹੋਏ ਟੈਕਸੋਨੋਮੀ ਰੱਖੋ। ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਡਿਫਾਲਟ:
ਹਰ ਆਈਟਮ ਇੱਕ ਛੋਟਾ, ਪੂਰਨ ਯੂਨਿਟ ਹੋਵੇ: ਕੀ ਬਦਲਿਆ, ਕਿਥੇ, ਪ੍ਰਭਾਵ, ਅਤੇ ਅਗਲਾ ਕਦਮ।
ਹਰ ਸ਼੍ਰੇਣੀ ਲਈ ਇੱਕ "ਨਵੀਂ ਚੇਂਜਲੋਗ ਐਂਟਰੀ" ਫਾਰਮ ਪ੍ਰਦਾਨ ਕਰੋ। ਉਦਾਹਰਨ ਵਜੋਂ, Changed ਟੈਮਪਲੇਟ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਸਕਦਾ ਹੈ:
ਟੈਮਪਲੇਟਾਂ ਰਿਵਿュー ਵਿੱਚ ਘੱਟ-ਵਾਪਸੀ ਅਤੇ ਵੱਖ-ਵੱਖ ਲੇਖਕਾਂ ਵਿੱਚ ਇੱਕਸਾਰਤਾ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਚੇਂਜਲੋਗ ਆਈਟਮ ਸਿਰਫ਼ ਲਿਖਤ ਨਾ ਰਹਿਣ—ਉਹ ਟ੍ਰੇਸ ਕਰਨਯੋਗ ਹੋਣ। ਲੇਖਕਾਂ ਨੂੰ ਇਹ ਚੀਜ਼ਾਂ ਜੋੜਨ ਦਿਓ:
POST /v1/payments)ਫਿਰ ਤੁਸੀਂ ਡੌਕ ਪੇਜ 'ਤੇ ਦਿਖਾ ਸਕਦੇ ਹੋ “ਇਹ ਪੇਜ ਰਿਲੀਜ਼ 2025.12 ਵਿੱਚ ਅਪਡੇਟ ਕੀਤਾ ਗਿਆ” ਅਤੇ ਚੇਂਜਲੋਗ ਐਂਟਰੀ ਆਪੋ-ਆਪ ਪ੍ਰਵਾਹਿਤ ਪੇਜ/ਐਂਡਪੋਇੰਟ ਦੀ ਸੂਚੀ ਦਿਖਾ ਸਕਦੀ ਹੈ।
ਯੂਜ਼ਰ ਆਮ ਤੌਰ 'ਤੇ ਸਾਰੀ ਇਤਿਹਾਸ ਨਹੀਂ ਚਾਹੁੰਦੇ। ਇਕ ਵਿਉ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਉਨ੍ਹਾਂ ਦੇ ਮੌਜੂਦਾ ਵਰਜ਼ਨ ਦੀ ਤੁਲਨਾ ਇੱਕ ਨਿਸ਼ਾਨੀ ਵਰਜ਼ਨ ਨਾਲ ਕਰਦੀ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਲਾਗੂ ਆਈਟਮ ਸੰਖੇਪ ਕਰਦੀ ਹੈ:
ਇੱਕ ਸਰਲ ਵਰਜ਼ਨ-ਟੂ-ਵਰਜ਼ਨ ਡਿਫਫ਼ ਵੀ ਚੰਗਾ ਹੈ ਜੇ ਫਿਲਟਰਿੰਗ ਭਲੀ-ਭਾਂਤਿ ਹੋਵੇ—ਇਹ ਲੰਬੇ ਚੇਂਜਲੋਗ ਨੂੰ ਕਾਰਗਰ ਅਪਗਰੇਡ ਯੋਜਨਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਵੱਖ-ਵੱਖ ਟੀਮਾਂ ਅਪਡੇਟ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਟਰੈਕ ਕਰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਕਈ ਆਉਟਪੁੱਟ ਦਿਓ:
ਫੀਡ URL ਸਥਿਰ ਰੱਖੋ ਅਤੇ ਅੰਦਰੂਨੀ ਪੇਜਾਂ ਲਈ ਰਿਲੇਟਿਵ ਲਿੰਕ ਵਰਤੋ ਤਾਂ ਕਿ ਖਪਤਕਾਰ ਡਾਇਰੈਕਟ ਵਿਵਰਣ 'ਤੇ ਜਾ ਸਕਣ।
ਖੋਜ਼ ਅਤੇ ਨੈਵੀਗੇਸ਼ਨ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ API ਡੌਕਿਊਮੈਂਟੇਸ਼ਨ ਇੱਕ ਵਰਤੋਂਯੋਗ ਡਿਵੈਲਪਰ ਪੋਰਟਲ ਬਣਦਾ ਹੈ। ਡਿਵੈਲਪਰ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਸਮੱਸਿਆ ਨਾਲ ਆਉਂਦੇ ਹਨ ("Webhook ਕਿਵੇਂ ਬਣਾਈਏ?") ਅਤੇ ਤੁਹਾਡਾ ਕੰਮ ਹੈ ਉਨ੍ਹਾਂ ਨੂੰ ਬਿਨਾਂ ਪਹਿਲਾਂ ਤੁਹਾਡੀ ਸਾਈਟ ਦੀ ਬਣਤਰ ਜਾਣੇ ਸਹੀ ਜਵਾਬ ਤਕ ਪਹੁੰਚਾਉਣਾ।
ਘੱਟੋ-ਘੱਟ, ਡੌਕ ਪੇਜਾਂ ਅਤੇ ਚੇਂਜਲੋਗ/ਰਿਲੀਜ਼ ਨੋਟ ਐਂਟਰੀਜ਼ 'ਤੇ ਫੁਲ-ਟੈਕਸਟ ਖੋਜ਼ ਸਹਾਇਤਾ ਕਰੋ। ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਹੀ ਨੋਲੇਜ ਬੇਸ ਵਜੋਂ ਸਿੱਧਾ ਕਰੋ ਤਾਂ ਕਿ ਉਪਭੋਗਤਾ “rate limits” ਖੋਜਣ ਤੇ ਡੌਕ ਪੇਜ ਅਤੇ ਉਸ ਰਿਲੀਜ਼ ਨੋਟ ਦੋਹਾਂ ਵੇਖ ਸਕਣ।
ਇੰਡੈਕਸ ਕਰਨ ਲਈ ਉਚਿਤ ਫੀਲਡਾਂ (ਟਾਈਟਲ, ਹੇਡਿੰਗ, ਬਾਡੀ, ਟੈਗ) ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਰਿਜ਼ਲਟਾਂ ਨੂੰ ਬੁਸਟ ਕਰੋ ਜਿਹੜੇ ਟਾਈਟਲ ਜਾਂ ਹੇਡਿੰਗ ਵਿੱਚ ਮਿਲਦੇ ਹਨ। ਛੋਟੇ ਸਨਿੱਪੇਟ ਦਿਖਾਓ ਜਿਸ ਵਿੱਚ ਮਿਲੀ ਸ਼ਬਦ ਸ਼ਾਮਲ ਹੋਂਦੇ ਹਨ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਨੂੰ ਕਲਿੱਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਇਹ ਪਤਾ ਲੱਗ ਜਾਵੇ ਕਿ ਉਹ ਸਹੀ ਨਤੀਜਾ ਹੈ।
ਖੋਜ਼ ਨਤੀਜੇ ਉਹ ਸਮੇਂ ਜ਼ਿਆਦਾ ਉਪਯੋਗੀ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਯੂਜ਼ਰ ਉਹਨਾਂ ਨੂੰ ਫਿਲਟਰ ਕਰ ਸਕਦੇ ਹਨ ਜਿਹੜੇ ਤੁਹਾਡੇ ਸਮੱਗਰੀ ਮਾਡਲ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ। ਆਮ ਫਿਲਟਰ:
UI ਨੂੰ ਕੰਟਰੋਲਾਂ ਦੇ ਭਰਵੀਂ ਢੇਰ ਵਿੱਚ ਨਹੀਂ ਬਦਲੋ। “ਪਹਿਲਾਂ ਖੋਜ਼, ਫਿਰ ਸੂੰਖੀ ਕਰੋ” ਵਰਗਾ ਪੈਟਰਨ ਚੰਗਾ ਰਹਿੰਦਾ ਹੈ, ਫਿਲਟਰ ਸਾਈਡ ਪੈਨਲ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਤੁਰੰਤ ਲਾਗੂ ਕਰੋ।
ਨੈਵੀਗੇਸ਼ਨ ਦੋਹਾਂ ਬ੍ਰਾਊਜ਼ਿੰਗ ਅਤੇ ਦਿਸ਼ਾ ਸਮਝਣ ਵਿੱਚ ਸਹਾਇਕ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:
Related pages ਟੈਗ, ਸਾਂਝੇ ਪੇਅਰੈਂਟ ਸੈਕਸ਼ਨ, ਜਾਂ ਮੈਨੂਅਲ ਕਰੇਸ਼ਨ ਨਾਲ ਚਲ ਸਕਦੇ ਹਨ। ਗੈਰ-ਤਕਨੀਕੀ ਟੀਮਾਂ ਲਈ, ਮੈਨੂਅਲ ਕਰੇਸ਼ਨ ਅਕਸਰ ਸਭ ਤੋਂ ਵਧੀਆ ਨਤੀਜੇ ਦਿੰਦੀ ਹੈ।
ਕੋਈ ਵੀ ਗਲਤ-ਖੁਲਾਸਾ ਭਰੋਸਾ ਤੋੜਦਾ ਹੈ। ਤੁਹਾਡੀ ਖੋਜ਼ ਇੰਡੈਕਸ ਅਤੇ ਨਤੀਜੇ ਕੋਸ਼ਿਸ਼ ਕਰਨਗੇ:
ਜੇ ਤੁਹਾਡੇ ਡੌਕਸ ਦੇ ਹਿੱਸੇ ਪਬਲਿਕ ਹਨ, ਤਾਂ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਕੁਝ SEO ਮੁਢਲੀਆਂ ਗੱਲਾਂ ਰੱਖੋ:
ਖੋਜ਼ ਅਤੇ ਖੋਜ ਹੀ ਲੋਕ ਤੁਹਾਡੀ ਡੌਕ ਦੀ ਤਜਰਬਾ ਹੁੰਦੀ ਹੈ। ਜੇ ਯੂਜ਼ਰ ਸਟੇਪ-ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਸਹੀ ਪੇਜ ਸੈਕਿੰਡਾਂ ਵਿੱਚ ਲੱਭ ਸਕਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਡੇ ਬਾਕੀ ਸਾਰੇ ਬਣਾਏ ਹੋਏ ਫੀਚਰ (ਵਰਜ਼ਨਿੰਗ, ਵਰਕਫਲੋ, ਅਪ੍ਰੂਵਲ) ਜ਼ਿਆਦਾ ਕੀਮਤੀ ਹੋ ਜਾਂਦੇ ਹਨ।
ਨੋਟੀਫਿਕੇਸ਼ਨ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਤੁਹਾਡਾ ਡੌਕਸ ਅਤੇ ਚੇਂਜਲੋਗ ਐਪ ਇੱਕ ਐਸੇ ਉਤਪਾਦ ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਜਿਸ 'ਤੇ ਲੋਕ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਲਕਸ਼ ਇਹ ਨਹੀਂ ਕਿ ਹੋਰ ਸੁਨੇਹੇ ਭੇਜੇ ਜਾਣ—ਲਕਸ਼ ਹੈ ਸਹੀ ਅਪਡੇਟ ਸਹੀ ਦਰਸ਼ਕ ਤੱਕ ਭੇਜਣਾ, ਸਾਫ਼ ਰਸਤਾ ਡੇਟੇਲਸ ਤੇ ਵਾਪਸ।
ਪਹਿਲਾਂ ਉਹ ਸਕੋਪ ਆਫਰ ਕਰੋ ਜੋ ਟੀਮਾਂ ਵਾਸਤੇ ਅਸਲ ਦੁਰੀ ਖਪਤ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ:
ਇਸ ਨਾਲ ਇੱਕ ਗਾਹਕ v1 'ਤੇ ਰਹਿ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਲਈ ਜ਼ਰੂਰੀ ਅਪਡੇਟ ਮਿਲਦੇ ਰਹਿਣਗੇ, ਬਿਨਾਂ v2-ਸਿਰਫ਼ ਬਦਲਾਵਾਂ ਨਾਲ ਜ਼ਗ੍ਹਾ ਭਰਪੂਰ ਕੀਤੇ ਬਿਨਾਂ।
ਘੱਟੋ-ਘੱਟ ਇੱਕ "ਮਨੁੱਖੀ" ਚੈਨਲ ਅਤੇ ਇੱਕ "ਮਸ਼ੀਨ" ਚੈਨਲ ਸਹਾਇਤਾ ਕਰੋ:
ਹਰ ਨੋਟੀਫਿਕੇਸ਼ਨ ਸਬ-ਕੰਟੈਕਸਟ ਲਈ ਡੀਪ-ਲਿੰਕ ਕਰੇ, ਉਦਾਹਰਨ: /docs/v2/overview, /changelog, ਜਾਂ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਐਂਟਰੀ /changelog/2025-12-01।
ਯੂਜ਼ਰਾਂ ਨੂੰ ਕੰਟਰੋਲ ਦਿਓ:
ਸਧਾਰਨ ਡਿਫਾਲਟ ਚੰਗਾ ਰਹਿੰਦਾ ਹੈ: breaking changes ਲਈ ਤੁਰੰਤ, ਹੋਰ ਸਭ ਲਈ ਡਾਈਜੇਸਟ।
ਇੱਕ ਇਨ-ਐਪ ਇਨਬਾਕਸ ਸ਼ਾਮਲ ਕਰੋ ਜਿਸ ਵਿੱਚ ਅਣਪੜ੍ਹੇ ਗਿਣਤੀ ਅਤੇ ਛੋਟੇ ਰਿਲੀਜ਼ ਹਾਈਲਾਈਟ ਹੋਣ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਵੇਖ ਸਕਣ ਕਿ ਕੀ ਬਦਲਿਆ ਹੈ। “Mark as read” ਅਤੇ “Save for later” ਕਾਰਵਾਈਆਂ ਰੱਖੋ, ਅਤੇ ਹਮੇਸ਼ਾਂ ਮੂਲ ਐਂਟਰੀ ਅਤੇ ਪ੍ਰਭਾਵਿਤ ਡੌਕ ਪੇਜ ਨੂੰ ਲਿੰਕ ਕਰੋ।
API ਡੌਕਸ ਅਤੇ ਚੇਂਜਲੋਗ ਐਪ ਦਾ ਸ਼ਿਪਿੰਗ ਵੱਡੇ ਲਾਂਚ ਦੀ ਥਾਂ ਭਰੋਸੇਯੋਗ ਇਟਰੇਸ਼ਨ ਬਾਰੇ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਹਲਕਾ ਟੈਸਟ ਸੁੱਟ, ਬੁਨਿਆਦੀ ਓਬਜ਼ਰਵੇਬਿਲਿਟੀ, ਅਤੇ ਦੋਹਰਾਉਣਯੋਗ ਡਿਪਲੋਏਮੈਂਟ ਰਸਤਾ ਤੁਹਾਨੂੰ ਤੋਂ-ਰਾਤ ਦੇ ਰੋਲਬੈਕਾਂ ਤੋਂ ਬਚਾਵੇਗਾ।
ਉਹਨਾਂ ਗੱਲਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਭਰੋਸੇ ਨੂੰ ਤੋੜਦੀਆਂ ਹਨ: ਗਲਤ ਸਮੱਗਰੀ, ਗਲਤ ਪਰਮਿਸ਼ਨ, ਅਤੇ ਪਬਲਿਸ਼ਿੰਗ ਮਿਸਟੇਕਸ।
End-to-end ਸੂਟ ਨੂੰ ਛੋਟਾ ਅਤੇ ਸਥਿਰ ਰੱਖੋ; ਯੂਜ਼ ਕੇਸਜ਼ ਅਤੇ ਏਜੀਟ ਕੇਸਜ਼ ਨੂੰ ਯੂਨਿਟ/API ਪੱਧਰ 'ਤੇ ਕਵਰ ਕਰੋ।
ਤਿੰਨ ਸਿਗਨਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਜਰੂਰਤ ਪੈਣ 'ਤੇ ਵਧਾਓ:
ਪ੍ਰਮਿਸ਼ਨ ਅਸੂਲ ਅਤੇ ਪਬਲਿਸ਼ ਇਵੈਂਟਾਂ ਨੂੰ ਲੌਗ ਕਰੋ—ਇਹ “ਮੈਨੂੰ ਕਿਉਂ ਨਹੀਂ ਦਿਖ ਰਿਹਾ?” ਦੀਆਂ ਰਿਪੋਰਟਾਂ ਸੁਲਝਾਉਣ ਲਈ ਕੀਮਤੀ ਹਨ।
ਹੁਣ-ਕਰਦਾ ਡਿਪਲੋਏਮੈਂਟ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਚਲਾਣਾ ਆਸਾਨ ਸਮਝੋ।
ਇੱਕ ਸਰਲ CI ਪਾਈਪਲਾਈਨ: tests ਚਲਾਓ, lint, build assets, migration ਕੱਦਮ ਵਿੱਚ ਚਲਾਓ, ਫਿਰ deploy। ਪ੍ਰੋਡਕਸ਼ਨ ਲਈ manual approval gate ਰੱਖੋ ਜੇ ਟੀਮ ਛੋਟੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਪਹਿਲਾ-ਡਿਪਲੋਏ ਘੱਟਾਉਣ ਦੇ ਇਰਾਦੇ ਨਾਲ ਹੋ, ਤਾਂ Koder.ai deployment ਅਤੇ hosting ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਸੰਭਾਲ ਸਕਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੀ ਪਾਇਪਲਾਈਨ ਤੇ ਜਾਣ ਲਈ ਤਿਆਰ ਹੋਵੋ ਤਾਂ ਜਨਰੇਟ ਕੀਤਾ ਸਰੋਤ ਕੋਡ ਨਿਰਯਾਤ ਕਰਨ ਦਿੰਦਾ ਹੈ।
ਡੇਟਾਬੇਸ ਅਤੇ ਫਾਇਲ ਸਟੋਰੇਜ (ਅਪਲੋਡ, ਨਿਕਾਸ ਕੀਤੇ ਐਸੈੱਟ) ਦੋਹਾਂ ਨੂੰ ਨਿਯਮਤ ਤਰੀਕੇ ਨਾਲ ਬੈਕਅੱਪ ਕਰੋ ਅਤੇ ਤਿਮਾਹੀ ਰੀਸਟੋਰ ਅਭਿਆਸ ਕਰੋ।
ਰੱਖ-ਰਖਾਵ ਲਈ ਰਿਕਰਿੰਗ ਚੈੱਕਲਿਸਟ: stale drafts ਹਟਾਓ, ਟੁੱਟੇ ਲਿੰਕ ਦੀ ਪਛਾਣ ਕਰੋ, ਪੁਰਾਣੀਆਂ ਵਰਜ਼ਨਾਂ ਨੂੰ ਆਰਕਾਈਵ ਜਾਂ ਡਿਪ੍ਰੀਕੇਟ ਕਰੋ, ਖੋਜ਼ ਨੂੰ ਦੁਬਾਰਾ ਇੰਡੈਕਸ ਕਰੋ, ਅਤੇ ਯੂਜ਼ਰ ਫੀਡਬੈਕ ਦਾ ਸਮੀਖਿਆ ਕਰਕੇ ਸੰਪਾਦਕ ਅਤੇ ਵਰਕਫਲੋ ਸੁਧਾਰਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ।
ਪਹਿਲਾਂ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਦਰਸ਼ਕ ਸਮੂਹ (ਅੰਦਰੂਨੀ ਟੀਮਾਂ, ਪਾਰਟਨਰ ਜਾਂ ਪਬਲਿਕ ਡਿਵੈਲਪਰ) ਚੁਣੋ ਅਤੇ ਉਹ ਮੁੱਖ ਦਰਦਾਂ ਲਿਖੋ ਜਿਹਨਾਂ ਨੂੰ ਤੁਸੀਂ ਹੱਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ (ਜਿਵੇਂ "ਸਪੋਰਟ canonical changelog ਐਂਟਰੀ ਨੂੰ ਲਿੰਕ ਨਹੀਂ ਕਰ ਸਕਦਾ"). ਫਿਰ ਕੁਝ ਮਾਪਨੇਯੋਗ ਮੈਟਰਿਕਸ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਉਦਾਹਰਨ ਲਈ:
ਇਹ ਪਾਬੰਦੀਆਂ MVP ਫੀਚਰ ਸੈਟ ਅਤੇ ਪਰਮਿਸ਼ਨ ਮਾਡਲ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਗੀਆਂ।
ਸਿਰਫ਼ ਉਹੀ ਚੀਜ਼ਾਂ ਪਹੁੰਚਾਓ ਜੋ ਮੁੱਖ ਪ੍ਰਕਾਸ਼ਨ ਲੂਪ ਨੂੰ ਸਹਾਇਤਾ ਕਰਨ। ਮਿਸਾਲ ਲਈ:
draft/published ਰਾਜ਼ਕੋਲੀਬਰੇਸ਼ਨ ਐਕਸਟਰਾਜ਼ (ਟਿੱਪਣੀਆਂ, ਐਨਾਲਿਟਿਕਸ, ਵੈੱਬਹੁਕ) ਨੂੰ ਓਹਲੇ ਰੱਖੋ ਜਦੋਂ ਤੱਕ ਟੀਮ ਭਰੋਸੇਯੋਗ ਅਪਡੇਟ ਪਬਲਿਸ਼ ਕਰ ਸਕਦੀ ਅਤੇ ਪਾਠਕ ਸਮਝ ਸਕਦੇ ਕਿ ਕੀ ਬਦਲਿਆ।
ਜੇ ਤੁਸੀਂ ਕੋਈ ਮਿਲੀ-ਜੁਲੀ ਪਬਲਿਕ, ਪਾਰਟਨਰ-ਖਾਸ ਅਤੇ ਅੰਦਰੂਨੀ ਸਮੱਗਰੀ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹਨੂੰ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਇੱਕ-ਪੱਖੀ ਲੋੜ ਵਜੋਂ ਲਓ:
ਸਮੱਗਰੀ ਅਤੇ URLs ਇਕ ਵਾਰੀ ਬਨ ਜਾਣ ਤੋਂ ਬਾਅਦ ਮਿਕਸਡ ਐਕਸੈਸ ਨੂੰ ਪਿੱਛੋਂ ਜੋੜਨਾ ਕਠਿਨ ਹੋ ਜਾਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਣ ਪਰ ਹੋਏ ਸਕੇਲ ਕਰਨਯੋਗ ਆਰਕੀਟੈਕਚਰ ਇਹ ਚਾਰ ਇਲਾਕਿਆਂ 'ਤੇ ਆਧਾਰਿਤ ਹੋ ਸਕਦੀ ਹੈ:
ਇਹ ਵੱਖ-ਵੱਖ ਭਾਗਾਂ ਨੂੰ ਅਲੱਗ-ਅਲੱਗ ਸਕੇਲ ਕਰਨ ਦਿੰਦੇ ਹਨ, ਤਾਂ ਕਿ ਭਾਰੀ ਖੋਜ਼ ਜਾਂ ਰੈਂਡਰਿੰਗ ਕੰਮ ਸੰਪਾਦਕ ਨੂੰ ਸਲੋ ਨਾ ਕਰੇ।
ਉਹ ਪੈਲੇ ਐਡਾਂ ਚੁਣੋ ਜਿਸਨੂੰ ਟੀਮ ਆਸਾਨੀ ਨਾਲ ਸ਼ਿਪ ਅਤੇ ਰੱਖ ਸਕੇ। ਆਮ ਤੌਰ 'ਤੇ ਚੰਗੀਆਂ ਵਿਕਲਪਾਂ:
ਫਰੰਟਐਂਡ ਲਈ React/Next.js ਅਕਸਰ SEO-ਮਿੱਤਰ ਡੌਕ ਪੇਜਾਂ ਅਤੇ ਮਸਰੂਫ਼ ਸੰਪਾਦਾਨ ਅਨੁਭਵ ਲਈ ਵਧੀਆ ਚੋਣ ਹੈ।
ਹਰ ਇਕ ਦੇ ਫਾਇਦੇ ਹਨ:
ਇਹ ਫੈਸਲਾ ਪਹਿਲੇ ਤੋਂ ਕਰੋ ਕਿਉਂਕਿ ਇਹ ਵਰਜ਼ਨਿੰਗ ਅਤੇ ਰਿਵਿਊ ਫਲੋ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਏਗਾ।