API ਕੁੰਜੀਆਂ ਲਈ Environment variables: ਇੱਕ ਸਧਾਰਨ ਰਾਜ਼ ਮਾਡਲ

API ਕੁੰਜੀਆਂ ਕਿਉਂ ਲੀਕ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

API ਕੁੰਜੀ ਕਿਸੇ ਸੇਵਾ ਲਈ ਪਾਸਵਰਡ ਵਾਂਗ ਹੈ (ਭੁਗਤਾਨ, ਈਮੇਲ, ਨਕਸ਼ੇ, AI, ਐਨਾਲਿਟਿਕਸ). ਇਹ ਸੇਵਾ ਨੂੰ ਦੱਸਦੀ ਹੈ, "ਇਹ ਬੇਨਤੀ ਮੇਰੇ ਅਕਾਊਂਟ ਤੋਂ ਆ ਰਹੀ ਹੈ," ਤਾਂ ਜੋ ਸੇਵਾ ਤੁਸੀਂ ਚਾਰਜ ਕਰ ਸਕੇ, ਸੀਮਾਵਾਂ ਲਗਾ ਸਕੇ ਅਤੇ ਪਹੁੰਚ ਦੇ ਸਕੇ।

ਕੁੰਜੀਆਂ ਲੀਕ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਵਾਰ ਉਹ ਇੱਕ ਤੇਜ਼ copy-paste ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਚੈਟ, settings ਫਾਇਲ, ਜਾਂ ਨੋਟ ਵਿੱਚ "ਸਿਰਫ਼ ਹੁਣ ਲਈ" ਪੇਸਟ ਕਰਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਇਹ ਕਿਤੇ ਇਸ਼ਤੇਮਾਲ ਹੋ ਕੇ ਸੇਵ ਹੋ ਜਾਂਦੀ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਸਾਂਝਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ।

ਆਮ ਅਣਜਾਣੀ ਲੀਕ ਦੇ ਰਸਤੇ ਚੈਟ ਪ੍ਰੰਪਟ ਹਨ (ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ vibe-coding ਟੂਲ ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੁੰਦੇ ਹੋ), ਕਿ ਰਿਪੋ ਵਿੱਚ ਇੱਕ ਕੁੰਜੀ commit ਕਰ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਜਾਂ "ਦੇਖਣ ਲਈ" ਜ਼ਿਪ ਅਪਲੋਡ ਕਰ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਸਕ੍ਰੀਨਸ਼ਾਟ ਜਾਂ ਸਕ੍ਰੀਨ-ਰਿਕਾਰਡਿੰਗ ਵਿੱਚ ਕੁੰਜੀ ਆ ਜਾਂਦੀ ਹੈ, ਜਾਂ ਇੱਕ ਸਾਂਝੇ ਦਸਤਾਵੇਜ਼ ਜਾਂ ਟੀਮ ਚੈਟ ਵਿੱਚ ਛੱਡ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਜਾਂ ਫਰੰਟ-ਐਂਡ ਕੋਡ ਵਿੱਚ hardcode ਹੋ ਜਾਂਦੀ ਹੈ ਜੋ ਕਿਸੇ ਵੀ ਬ੍ਰਾੳਜ਼ਰ ਨਾਲ ਪੜ੍ਹੀ ਜਾ ਸਕਦੀ ਹੈ।

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

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

ਇੱਕ ਸਧਾਰਨ ਮਾਨਸਿਕ ਮਾਡਲ: ਕੋਡ, ਕনফਿਗ, ਰਾਜ਼

ਜੇ ਤੁਸੀਂ ਇੱਕ ਨਿਯਮ ਯਾਦ ਰੱਖੋ ਤਾਂ ਇਹ ਹੋਵੇ: ਕੋਡ ਉਹ ਹੈ ਜੋ ਤੁਹਾਡਾ ਐਪ ਕਰਦਾ ਹੈ, ਕਨਫਿਗ ਉਹ ਹੈ ਕਿ ਇਹ ਕਿਵੇਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਰਾਜ਼ ਉਹ ਹੈ ਜੋ ਕਦੇ ਵੀ ਬੇਨਕਾਬ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।

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

ਕਨਫਿਗ ਉਹ ਸੈਟਿੰਗ ਹੈ ਜੋ ਪਬਲਿਕ ਹੋ ਸਕਦੀ ਹੈ ਬਿਨਾਂ ਨੁਕਸਾਨ ਦੇ। ਸੋਚੋ: ਤੁਹਾਡਾ ਐਪ ਨਾਮ, ਕਿਹੜੇ ਰੀਜਨ ਵਿੱਚ ਦੌੜਣਾ ਹੈ, ਫੀਚਰ ਫਲੈਗ, ਜਾਂ ਕਿਸੇ ਸੇਵਾ ਦੀ ਬੇਸ URL। ਜੇ ਕੋਈ ਇਹ ਵੇਖ ਲਏ ਤਾਂ ਉਹ ਤੁਹਾਡੇ ਪੈਸੇ ਖਰਚ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਨਿੱਜੀ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਜਾਂ ਤੁਹਾਡੀ ਨਕਲ ਨਹੀਂ ਕਰ ਸਕਦਾ।

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

ਇਕ environment variable ਸਿਰਫ਼ ਇੱਕ ਲੇਬਲ ਕੀਤਾ ਹੋਇਆ ਸਲੌਟ ਹੈ ਜੋ ਤੁਹਾਡਾ ਐਪ ਚਲਦੇ ਸਮੇਂ ਪੜ੍ਹਦਾ ਹੈ। ਤੁਹਾਡਾ ਕੋਡ ਇੱਕ ਲੇਬਲ ਲੱਭਦਾ ਹੈ (ਜਿਵੇਂ STRIPE_SECRET_KEY) ਅਤੇ ਜੋ ਵੀ ਮੁੱਲ ਉਸ ਸਮੇਂ ਰੱਖਿਆ ਗਿਆ ਹੈ ਉਹ ਵਰਤਦਾ ਹੈ। ਇਹ ਵੱਖ-ਵੱਖ ਕਰਨ ਦੀ ਇਹੀ ਵਜ੍ਹਾ ਹੈ ਕਿ Environment variables API ਕੁੰਜੀਆਂ ਲਈ ਬਹੁਤ ਚੰਗੇ ਕੰਮ ਕਰਦੇ ਹਨ: ਕੋਡ ਇੱਕੋ ਜਿਹਾ ਰਹਿੰਦਾ ਹੈ, ਪਰ ਰਾਜ਼ ਮੁੱਲ ਤੁਹਾਡੇ ਪ੍ਰੰਪਟ, ਫਾਇਲਾਂ ਅਤੇ ਰਿਪੋ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦਾ ਹੈ।

ਕੋਡ ਅਤੇ ਰਾਜ਼ ਨੂੰ ਵੱਖਰਾ ਰੱਖਣਾ ਫਿਕਸ ਕਰਨਾ ਵੀ ਆਸਾਨ ਬਣਾਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਕਦੇ ਅਕਸਮਾਤ ਰਾਜ਼ ਉਜਾਗਰ ਕਰ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਮੁੱਲ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਕੋਡ ਨੂੰ ਛੇੜੇ।

ਇੱਕ ਪ੍ਰਯੋਗੀ ਤਰੀਕਾ ਵਾਤਾਵਰਣਾਂ ਬਾਰੇ ਸੋਚਣ ਦੀ: ਇੱਕੋ ਲੇਬਲ, ਵੱਖਰੇ ਮੁੱਲ।

• Dev: ਤੁਹਾਡੇ ਨਿੱਜੀ ਕੁੰਜੀ ਅਤੇ ਟੈਸਟ ਸੇਵਾਵਾਂ
• Staging: ਪ੍ਰੋਡਕਸ਼ਨ ਵਿਵਹਾਰ ਦੀ ਸੇਫ਼ ਨਕਲ, ਹਲੇ ਵੀ ਗੈਰ-ਪ੍ਰੋਡਕਸ਼ਨ ਅਧਿਕਾਰਾਂ ਨਾਲ
• Prod: ਅਸਲ ਕੁੰਜੀਆਂ, ਅਸਲ ਪੈਸਾ, ਅਸਲ ਡੇਟਾ

ਉਦਾਹਰਣ: ਤੁਸੀਂ ਹਰ ਜਗ੍ਹਾ PAYMENTS_KEY ਲੇਬਲ ਵਰਤ ਸਕਦੇ ਹੋ, ਪਰ dev ਇੱਕ ਟੈਸਟ ਕੁੰਜੀ ਵਰਤੇਗਾ, staging ਇੱਕ ਸੀਮਿਤ ਕੁੰਜੀ ਵਰਤੇਗਾ, ਅਤੇ prod ਪੂਰੀ ਲਾਈਵ ਕੁੰਜੀ ਵਰਤੇਗਾ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਪਲੇਟਫਾਰਮ ਵਰਗਾ Koder.ai ਨਾਲ ਡਿਪਲੋਏ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਸਾਫ਼ ਮੇਲ ਖਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇੱਕੋ ਐਪ ਨੂੰ ਵੱਖ-ਵੱਖ ਬਾਤਾਵਰਣਾਂ 'ਤੇ ਵੱਖ-ਵੱਖ environment settings ਨਾਲ ਡਿਪਲੋਏ ਕਰ ਸਕਦੇ ਹੋ।

ਕੀ ਗੱਲ ਰਾਜ਼ ਹੈ (ਅਤੇ ਕੀ ਨਹੀਂ)

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

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

ਕੁਝ ਮੁੱਲ ਹੈਰਾਨ ਕਰਨ ਵਾਲੇ ਲੱਗਦੇ ਹਨ ਪਰ ਫਿਰ ਵੀ ਸੰਵੇਦਨਸ਼ੀਲ ਹਨ। Write tokens ਇਕ ਆਮ ਫੰਸ ਹਨ: ਇਹ ਪਾਸਵਰਡ ਵਰਗੇ ਨਹੀਂ ਲੱਗਦੇ, ਪਰ ਇਹ ਹਮਲਾਵਰ ਨੂੰ ਬਦਲ ਕਰਨ, ਫਾਈਲ ਅਪਲੋਡ ਕਰਨ, ਈਮੇਲ ਭੇਜਣ ਜਾਂ ਡੇਟਾਬੇਸ ਨੂੰ ਲਿਖਣ ਦਿੱਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਐਡਮਿਨ ਕੁੰਜੀਆਂ, ਸਰਵਿਸ ਅਕਾਊਂਟ JSON ਫਾਈਲਾਂ, ਅਤੇ ਕੋਈ ਵੀ ਲੰਬੀ ਰੈਂਡਮ ਸਟ੍ਰਿੰਗ ਵਾਲਾ ਟੋਕਨ ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਹਨ।

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

ਇਕ ਤੇਜ਼ ਟੈਸਟ: ਜੇ ਤੁਸੀਂ ਇਹ ਦੇਖ ਕੇ ਨਾਰਾਜ਼ ਹੋ ਜਾਓਗੇ ਕਿ ਇਹ ਕਿਸੇ ਪਬਲਿਕ ਚੈਟ ਵਿੱਚ ਚਿਪਕਾਇਆ ਗਿਆ ਹੈ ਜਾਂ ਪਬਲਿਕ ਰਿਪੋ ਵਿੱਚ commit ਹੋਇਆ ਹੈ, ਤਾਂ ਇਹ ਰਾਜ਼ ਹੈ।

ਆਪਣੇ ਐਪ ਦੇ ਰਾਜ਼ਾਂ ਦੀ ਇੱਕ ਛੋਟੀ ਲਿਖਤੀ ਲਿਸਟ ਰੱਖੋ। ਹਰ ਇਕ ਲਈ ਲਿਖੋ ਕਿ ਇਹ ਕਿਸ ਲਈ ਹੈ (ਭੁਗਤਾਨ, ਈਮੇਲ, ਡੇਟਾਬੇਸ, ਸਟੋਰੇਜ), ਕਿੱਥੇ ਰਹਿੱਸ (dev, staging, prod), ਕੌਣ ਜ਼ਿੰਮੇਵਾਰ ਹੈ (ਤੁਸੀਂ, ਕੋਈ ਟੀਮੀ ਮਿਤਰ, ਵੇਂਡਰ ਅਕਾਊਂਟ), ਅਤੇ ਕੀ ਇਹ read-only ਹੈ ਜਾਂ write ਐਕਸੈਸ ਹੈ। ਇਹ ਲਿਸਟ ਬਾਦ ਵਿੱਚ ਤੁਹਾਡੇ ਲਈ ਪਹੁੰਚ ਦਾ ਨਕਸ਼ਾ ਬਣੇਗੀ ਜਦੋਂ ਤੁਸੀਂ ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਏ ਕੁੰਜੀਆਂ ਰੋਟੇਟ ਕਰੋਗੇ।

ਰਾਜ਼ ਆਕਸਮਾਤ ਕਿੱਥੇ ਪਹੁੰਚ ਜਾਂਦੇ ਹਨ

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

ਚੈਟ ਇਕ ਵੱਡਾ ਸੌਰਸ ਹੈ। ਲੋਕ ਮੁਕੰਮਲ API ਕੁੰਜੀਆਂ ਪ੍ਰੰਪਟ, ਟੀਮ ਚੈਟ ਜਾਂ ਸਪੋਰਟ ਸੁਨੇਹਿਆਂ ਵਿੱਚ ਪੇਸਟ ਕਰ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਪਰ ਚੈਟ ਸੇਵ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਸਾਂਝੇ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਜੇ ਤੁਹਾਨੂੰ ਮਦਦ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਸਿਰਫ਼ ਆਖਰੀ 4-6 ਕੀਰਦਾਰ ਅਤੇ ਕੁੰਜੀ ਨਾਮ ਪੇਸਟ ਕਰੋ, ਜਿਵੇਂ STRIPE_SECRET_KEY ...9f2a।

Git ਕਲਾਸਿਕ ਫੰਸ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਫਾਇਲ ਵਿੱਚ "ਸਿਰਫ਼ ਹੁਣ ਲਈ" ਇੱਕ ਕੁੰਜੀ ਜੋੜਦੇ ਹੋ, commit ਕਰਦੇ ਹੋ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਹਟਾਉਂਦੇ ਹੋ। ਰਾਜ਼ ਹਜੇ ਵੀ commit ਇਤਿਹਾਸ ਵਿੱਚ ਮੌਜੂਦ ਰਹਿੰਦਾ ਹੈ। ਇਹ forks, ਕਾਪੀ ਕੀਤੀਆਂ ਸਨਿੱਪੇਟਾਂ ਜਾਂ pull request diffs ਰਾਹੀਂ ਵੀ ਫੈਲ ਸਕਦਾ ਹੈ।

ਸਕ੍ਰੀਨਸ਼ਾਟ ਅਤੇ ਸਕ੍ਰੀਨ ਰਿਕਾਰਡਿੰਗਜ਼ ਅਧਿਕ ਤਰ੍ਹਾਂ ਲੀਕ ਕਰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਉਮੀਦ ਘੱਟ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਡੈਮੋ ਵੀਡੀਓ ਇੱਕ settings ਸਕ੍ਰੀਨ, ਟਰਮੀਨਲ ਕਮਾਂਡ ਜਾਂ ਐਰਰ ਸੁਨੇਹਾ ਕੈਪਚਰ ਕਰ ਸਕਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਟੋਕਨ ਦਿਖਾਈ ਦੇ ਰਿਹਾ ਹੈ। ਭੁੰਝੇ ਹੋਏ ਟੈਕਸਟ ਵੀ ਖਤਰੇਯੋਗ ਹੋ ਸਕਦੇ ਹਨ ਜੇ ਹੋਰ ਹਿੱਸੇ ਦਿੱਖ ਰਹੇ ਹਨ।

ਇਸ਼ੂ ਟਰੈੱਕਰ ਅਤੇ ਨੋਟ ਐਪਸ ਇਕ ਹੋਰ ਸ਼ਾਂਤ ਸਰੋਤ ਹਨ। ਟਿਕਟ, ਚੈਕਲਿਸਟ ਅਤੇ ਸਾਂਝੇ ਦਸਤਾਵੇਜ਼ ਟੀਮਾਂ ਅਤੇ ਵੇਂਡਰਾਂ ਵਿੱਚ ਨਕਲ ਹੋ ਜਾਂਦੇ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਪਬਲਿਕ ਲੌਗ ਸਮਝੋ।

ਕੁਝ ਆਦਤਾਂ ਜ਼ਿਆਦਾਤਰ ਲੀਕਾਂ ਨੂੰ ਰੋਕਦੀਆਂ ਹਨ:

• ਕਦੇ ਵੀ ਪੂਰੀਆਂ ਕੁੰਜੀਆਂ ਚੈਟ, ਟਿਕਟ ਜਾਂ ਪ੍ਰੰਪਟ ਵਿੱਚ ਪੇਸਟ ਨਾ ਕਰੋ।
• ਕੋਡ, ਕਨਫਿਗ ਫਾਇਲਾਂ ਅਤੇ ਸਕ੍ਰੀਨਸ਼ਾਟ ਵਿੱਚ ਰਾਜ਼ ਰੱਖੋ ਹੀ ਨਾ।
• ਡੈਮੋ ਵਿੱਚ ਮੁੱਲਾਂ ਨੂੰ ਰੈਡੈਕਟ ਕਰੋ (ਵਿੰਡੋ ਲੁਕਾਓ ਜਾਂ ਪਲੇਸਹੋਲਡਰ ਵਰਤੋ)।
• ਜੇ ਕੋਈ ਕੁੰਜੀ ਉਜਾਗਰ ਹੋ ਗਈ ਤਾਂ assume ਕਰੋ ਕਿ ਉਹ ਸਮਰੱਥ ਹੈ ਅਤੇ ਉਸਨੂੰ ਰੋਟੇਟ ਕਰੋ।
• ਇੱਕ ਛੋਟੀ "ਕਿੱਥੇ ਵਰਤਿਆ" ਨੋਟ ਰੱਖੋ (ਸੇਵਾ ਦਾ ਨਾਮ ਅਤੇ environment) ਤਾਂ ਕਿ ਰੋਟੇਸ਼ਨ ਆਸਾਨ ਹੋਵੇ।

ਜੇ ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਉਹੀ ਮਨੋਵਿਰਤੀ ਵਰਤੋ: ਸੰਵੇਦਨਸ਼ੀਲ ਮੁੱਲਾਂ ਨੂੰ environment settings ਵਿੱਚ ਰੱਖੋ, ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਵਾਲੇ ਚੈਟ ਵਿੱਚ ਨਹੀਂ।

ਕਦਮ-ਬੰਦ ਤਰੀਕਾ: ਲੋਕਲੀ ਰਾਜ਼ ਸੈੱਟ ਕਰਨਾ env vars ਨਾਲ

ਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਤੁਹਾਡਾ ਐਪ ਰਾਜ਼ਾਂ ਨੂੰ environment ਤੋਂ ਪੜ੍ਹੇ, ਨਾ ਕਿ ਤੁਹਾਡੇ ਪ੍ਰੰਪਟ ਤੋਂ, ਨਾ ਤੁਹਾਡੇ ਕੋਡ ਤੋਂ, ਅਤੇ ਨਾ ਉਹ ਫਾਇਲਾਂ ਜੋ Git ਵਿੱਚ ਪਹੁੰਚ ਸਕਦੀਆਂ ਹਨ।

1) ਲੋਕਲ .env ਫਾਇਲ ਵਰਤੋ (ਅਤੇ Git ਤੋਂ ਬਾਹਰ ਰੱਖੋ)

.env ਫਾਇਲ ਤੁਹਾਡੇ ਮਸ਼ੀਨ ਤੇ ਸਧਾਰਨ ਟੈਕਸਟ ਫਾਇਲ ਹੁੰਦੀ ਹੈ ਜੋ key-value ਜੋੜੇ ਸਟੋਰ ਕਰਦੀ ਹੈ। ਇਹ ਲੋਕਲ ਸੈਟਅਪ ਆਸਾਨ ਕਰਦੀ ਹੈ, ਪਰ ਇਹ ਵੀ ਆਸਾਨੀ ਨਾਲ ਲੀਕ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਵਾਲਟ ਵਾਂਗ ਰੱਖੋ।

ਲੋਕਲ .env ਫਾਇਲ ਬਣਾਓ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ Git ਦੁਆਰਾ ignore ਕੀਤੀ ਗਈ ਹੈ (ਆਮ ਤੌਰ 'ਤੇ .gitignore ਰਾਹੀਂ)। ਜੇ ਤੁਹਾਨੂੰ ਟੀਮ ਮਿਤਰਾਂ ਨਾਲ ਵੈਰੀਏਬਲ ਦੇ ਨਾਂ ਸਾਂਝੇ ਕਰਨੇ ਹਨ, ਤਾਂ ਇੱਕ ਨਮੂਨਾ ਫਾਇਲ ਜਿਵੇਂ .env.example ਸਾਂਝਾ ਕਰੋ ਜਿਸ ਵਿੱਚ ਸਿਰਫ ਪਲੇਸਹੋਲਡਰ ਹੋਣ, ਅਸਲ ਮੁੱਲ ਨਹੀਂ।

2) ਵੈਰੀਏਬਲਾਂ ਦੇ ਨਾਮ ਇਸ ਤਰ੍ਹਾਂ ਰੱਖੋ ਕਿ ਕੋਈ ਗਲਤ ਨਾ ਸਮਝੇ

ਸਪਸ਼ਟ ਨਾਮ ਚੁਣੋ ਤਾਂ ਜੋ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਕਿ ਉਹ ਕੀ ਹਨ ਅਤੇ ਕਿੱਥੇ belong ਕਰਦੇ ਹਨ:

• OPENAI_API_KEY
• STRIPE_SECRET_KEY
• DATABASE_URL
• SENDGRID_API_KEY
• S3_ACCESS_KEY_ID

ਚੰਗੇ ਨਾਮ ਇਸ ਗਲਤੀ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ dev, staging ਅਤੇ production ਸੈੱਟ ਕਰਦੇ ਹੋ।

3) ਤੁਹਾਡਾ ਐਪ env vars ਕਿਸ ਤਰ੍ਹਾਂ ਵਰਤਦਾ ਹੈ (ਸੈਧਾਂਤਿਕ)

ਜਦੋਂ ਐਪ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਇਹ ਓਐਸ ਤੋਂ ਪੁੱਛਦਾ ਹੈ, "ਕੀ ਤੁਹਾਡੇ ਕੋਲ OPENAI_API_KEY ਲਈ ਕੋਈ ਮੁੱਲ ਹੈ?" ਜੇ ਮੁੱਲ ਮੌਜੂਦ ਹੈ ਤਾਂ ਐਪ ਇਸਨੂੰ ਵਰਤਦਾ ਹੈ। ਜੇ ਇਹ ਗੈਰ-ਮੌਜੂਦ ਹੈ ਤਾਂ ਐਪ ਨੂੰ ਸਪੱਸ਼ਟ ਗਲਤੀ ਦੇ ਕੇ ਅਗੇ ਨਹੀਂ ਚੱਲਣਾ ਚਾਹੀਦਾ।

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

4) ਟੀਮ ਦੇ ਅੰਦਰ ਰਾਜ਼ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸਾਂਝਾ ਕਰੋ

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

ਉਦਾਹਰਣ: ਇੱਕ ਫਾਊਂਡਰ Koder.ai ਪ੍ਰੋਜੈਕਟ export ਕਰਦਾ ਹੈ ਅਤੇ ਲੋਕਲੀ ਰਨ ਕਰਦਾ ਹੈ। ਉਹ .env ਆਪਣੀ ਲੈਪਟਾਪ 'ਤੇ ਰੱਖਦਾ ਹੈ, ਸਿਰਫ .env.example commit ਕਰਦਾ ਹੈ, ਅਤੇ ਟੀਮ ਨੂੰ ਅਸਲ ਕੁੰਜੀਆਂ ਇੱਕ ਸ਼ੇਅਰਡ ਪਾਸਵਰਡ ਮੈਨੇਜਰ ਰਾਹੀਂ ਦਿੰਦਾ ਹੈ।

ਕਦਮ-ਬੰਦ ਤਰੀਕਾ: dev, staging, prod ਵਿੱਚ env vars ਨਕਸ਼ਾ ਬਣਾਉਣਾ

ਵਾਤਾਵਰਣਾਂ ਨੂੰ ਤਿੰਨ ਵੱਖਰੇ ਕਮਰੇ ਵਾਂਗ ਸੋਚੋ।

Dev ਤੁਹਾਡੀ ਲੈਪਟਾਪ ਜਾਂ ਨਿੱਜੀ ਸੈਂਡਬਾਕਸ ਹੈ ਜਿਥੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਾਵ ਕਰਦੇ ਹੋ। Staging ਪ੍ਰੋਡਕਸ਼ਨ ਦੀ ਸੇਫ਼ ਨਕਲ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਪੂਰਾ ਐਪ ਟੈਸਟ ਕਰਦੇ ਹੋ ਪਰ ਗਾਹਕਾਂ 'ਤੇ ਅਸਰ ਨਹੀਂ ਹੁੰਦਾ। Prod ਉਹ ਹੈ ਜੋ ਗਾਹਕ ਵਰਤਦੇ ਹਨ।

ਸਧਾਰਨ ਨਿਯਮ: ਹਰ ਜਗ੍ਹਾ ਵੈਰੀਏਬਲ ਨਾਮ ਇਕੋ ਰੱਖੋ, ਅਤੇ ਸਿਰਫ ਮੁੱਲ ਬਦਲੋ। ਤੁਹਾਡਾ ਕੋਡ ਹਰ ਵਾਤਾਵਰਣ ਵਿੱਚ STRIPE_SECRET_KEY ਪੜ੍ਹੇਗਾ, ਪਰ ਹਰ ਵਾਤਾਵਰਣ ਇੱਕ ਵੱਖਰਾ ਕੁੰਜੀ ਪ੍ਰਦਾਨ ਕਰੇਗਾ।

ਇੱਕ ਸਧਾਰਨ ਨਕਸ਼ਾ ਨੋਟ (ਇੱਕ ਛੋਟੀ ਨੋਟ ਵੀ ਚੱਲਦੀ ਹੈ) ਮਦਦ ਕਰਦੀ ਹੈ:

Prod ਨੂੰ dev ਕੁੰਜੀਆਂ ਦੁਬਾਰਾ ਨਹੀਂ ਵਰਤਣੀਆਂ ਚਾਹੀਦੀਆਂ। Dev ਕੁੰਜੀਆਂ ਅਕਸਰ ਟੀਮ-ਸਾਂਝੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਕਈ ਵਾਰੀ ਵਿਆਪਕ ਅਧਿਕਾਰ ਹੁੰਦੇ ਹਨ।

ਛੋਟੇ ਟੀਮ ਨਾਲ environment ਮੁੱਲਾਂ ਨੂੰ ਸੰਗਠਿਤ ਰੱਖਣ ਲਈ ਕੁਝ ਨਿਯਮਾਂ 'ਤੇ ਰਾਜਮੰਡਲ ਕਰੋ:

• ਇੱਕ ਵਿਅਕਤੀ env var ਲਿਸਟ ਦਾ ਮਾਲਕ ਹੋਵੇ ਅਤੇ ਇਸਨੂੰ ਅਪਡੇਟ ਰੱਖੇ।
• ਹਰ ਸੈਟਿੰਗ ਲਈ ਇਕ ਨਾਂ (ਜੈਸਾ STRIPE_KEY vs STRIPE_API_KEY ਵਰਗੇ duplicates ਨਾ ਹੋਣ)।
• ਮੁੱਲਾਂ ਨੂੰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਸਰਕਾਰੀ ਸਥਾਨ ਵਿੱਚ ਰੱਖੋ, ਚੈਟ ਸੁਨੇਹਿਆਂ ਜਾਂ ਰੈਂਡਮ ਡੌਕਸ ਵਿੱਚ ਨਹੀਂ।
• ਸਟੇਜਿੰਗ ਵਿੱਚ ਨਵੇਂ ਕੁੰਜੀਆਂ ਟੈਸਟ ਕਰੋ ਪਹਿਲਾਂ, ਫਿਰ ਪ੍ਰੋਡ ਵਿੱਚ ਬਦਲੋ।
• ਆਖਰੀ ਰੋਟੇਸ਼ਨ ਦੀ ਤਾਰੀਖ ਅਤੇ ਜਿਸਨੇ ਰੋਟੇਟ ਕੀਤਾ ਉਸਦਾ ਨਾਂ ਲਿਖੋ।

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗਾ ਹੋਸਟਡ ਬਿਲਡਰ ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਹਰ ਡਿਪਲੋਇਮੈਂਟ ਟਾਰਗਟ (dev, staging, prod) ਨੂੰ ਵੱਖ-ਵੱਖ ਵਾਤਾਵਰਣ ਸਮਝੋ ਜਿਸ ਵਿੱਚ ਆਪਣੀਆਂ secret values ہوں, ਭਾਵੇਂ ਕੋਡ ਇੱਕੋ ਹੋਵੇ।

ਰਾਜ਼ ਬਿਨਾਂ ਐਪ ਨੂੰ ਤੋੜੇ ਕਿਵੇਂ ਰੋਟੇਟ ਕਰੀਏ

ਰੋਟੇਟ ਕਰਨਦਾ ਮਤਲਬ ਹੈ ਇਕ API ਕੁੰਜੀ ਇਰਾਦੇ ਨਾਲ, ਆਪਣੇ ਸਮਾਂ-ਸਾਰਣੀ 'ਤੇ, ਬਦਲਣਾ। ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਤਾਂ ਰੋਟੇਸ਼ਨ ਬੇਹਦ ਸਧਾਰਨ ਹੁੰਦੀ ਹੈ: ਤੁਸੀਂ ਕੁੰਜੀ ਬਦਲਦੇ ਹੋ, ਸਭ ਕੁਝ ਵੀਚਾਰ ਕਰਕੇ ਜਾਂਚਦੇ ਹੋ, ਫਿਰ ਪੁਰਾਣੀ ਨੂੰ ਅਯੋਗ ਕਰ ਦਿੰਦੇ ਹੋ।

ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਮਾਨਸਿਕ ਮਾਡਲ "ਥੋੜੇ ਸਮੇਂ ਲਈ ਦੋ ਕੁੰਜੀਆਂ" ਹੈ। ਬਹੁਤ ਸੇ ਪ੍ਰੋਵਾਈਡਰ ਇੱਕ ਤੋਂ ਵੱਧ ਸਰਗਰਮ ਕੁੰਜੀਆਂ ਬਣਾਉਣ ਦਿੰਦੇ ਹਨ। ਉਹ overlap ਹੀ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਕਨਫਿਗ ਬਦਲ ਰਹੇ ਹੁੰਦੇ ਹੋ।

ਸਧਾਰਨ ਰੋਟੇਸ਼ਨ ਵਿੰਡੋ ਇਹ ਹੈ:

• ਪ੍ਰਦਾਤਾ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਨਵੀਂ ਕੁੰਜੀ ਬਣਾਓ (ਹੋਣ ਵਾਲੀ ਪੁਰਾਣੀ ਨੂੰ ਅਜੇ ਮਿਟਾਓ ਨਾ)।
• ਉਸ ਵੈਰੀਏਬਲ ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ ਜਿੱਥੇ ਤੁਹਾਡਾ ਐਪ ਇਸਨੂੰ ਪੜ੍ਹਦਾ ਹੈ (ਲੋਕਲ env, ਹੋਸਟਿੰਗ ਸੈਟਿੰਗਜ਼, ਜਾਂ ਪਲੇਟਫਾਰਮ env settings)।
• ਐਪ ਨੂੰ deploy ਜਾਂ restart ਕਰੋ ਤਾਂ ਜੋ ਨਵੀਂ ਮੁੱਲ ਲੋਡ ਹੋ ਜਾਵੇ।
• ਅਸਲੀ ਵਰਕਫਲੋ ਦੀ ਜਾਂਚ ਕਰੋ (ਟੈਸਟ ਈਮੇਲ ਭੇਜੋ, ਟੈਸਟ ਪੇਮੈਂਟ ਕਰੋ, ਨਕਸ਼ਾ ਲੋਡ ਕਰੋ)।
• ਜਦੋਂ ਤੁਸੀਂ ਨਵੀਂ ਕੁੰਜੀ ਤੇ ਭਰੋਸਾ ਹੋ ਜਾਏ ਤਾਂ ਪੁਰਾਣੀ ਕੁੰਜੀ ਰੱਦ ਕਰੋ।

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

ਜੇ ਤੁਹਾਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਇੱਕ ਕੁੰਜੀ ਲੀਕ ਹੋ ਗਈ, ਤਾਂ ਪਹਿਲਾਂ ਕਾਰਵਾਈ ਕਰੋ ਅਤੇ ਦੂਸਰੇ ਕਦਮ ਬਾਅਦ ਕਰੋ। ਤੁਰੰਤ ਕੁੰਜੀ ਰੱਦ ਜਾਂ ਡਿਸੇਬਲ ਕਰੋ, ਫਿਰ ਨਵੀਂ ਜਾਰੀ ਕਰੋ ਅਤੇ ਆਪਣੀ environment variable ਅੱਪਡੇਟ ਕਰੋ। ਜਦੋਂ ਐਪ ਮੁੜ ਸਥਿਰ ਹੋ ਜਾਵੇ, ਤਦ ਵੇਖੋ ਕਿ ਇਹ ਕਿੱਥੋਂ ਲੀਕ ਹੋਈ: ਚੈਟ ਪ੍ਰੰਪਟ, build logs, ਸਕ੍ਰੀਨਸ਼ਾਟ, ਪੁਰਾਣੇ commits, ਜਾਂ ਸਾਂਝੇ ਦਸਤਾਵੇਜ਼।

ਉਦਾਹਰਣ: ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਇੱਕ ਛੋਟਾ CRM ਬਣਾਇਆ ਹੈ ਜੋ ਈਮੇਲ API ਵਰਤਦਾ ਹੈ। ਤੁਸੀਂ ਨਵੀਂ ਈਮੇਲ ਕੁੰਜੀ ਬਣਾਂਦੇ ਹੋ, ਇਸਨੂੰ ਐਪ ਦੇ environment settings ਵਿੱਚ ਸੈੱਟ ਕਰਦੇ ਹੋ, ਇੱਕ ਟੈਸਟ ਈਮੇਲ ਚਲਾਉਂਦੇ ਹੋ, ਫਿਰ ਪੁਰਾਣੀ ਕੁੰਜੀ ਰੱਦ ਕਰ ਦਿੰਦੇ ਹੋ।

ਡਿਪਲੋਇਮੈਂਟ ਅਤੇ CI: ਪ੍ਰੋਡ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਰਾਜ਼ ਲੈ ਜਾਣਾ

CI/CD ਇੱਕ ਆਟੋਮੈਟਿਕ ਪਾਈਪਲਾਈਨ ਹੈ ਜੋ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਬਿਲਡ ਅਤੇ ਡਿਪਲੋਏ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਬਦਲਾਅ ਭੇਜਦੇ ਹੋ, ਅਤੇ ਇਹ ਅਕਸਰ ਉਹੀ ਰਾਜ਼ਾਂ ਚਾਹੀਦੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਚਾਹੀਦੀਆਂ ਹਨ।

ਮੁੱਖ ਨਿਯਮ: API ਕੁੰਜੀਆਂ ਨੂੰ build logs, source code ਜਾਂ ਚੈਟ ਪ੍ਰੰਪਟ ਵਿੱਚ ਨਾ ਛੁਪਾਓ। ਪਾਈਪਲਾਈਨ ਨੂੰ ਇੱਕ ਹੋਰ ਕਮਪਿਊਟਰ ਵਾਂਗ علاج ਕਰੋ ਜੋ ਸੰਯਮਤ ਤਰੀਕੇ ਨਾਲ ਰਾਜ਼ ਪ੍ਰਾਪਤ ਕਰੇ।

ਬਿਲਡ-ਟਾਈਮ ਰਾਜ਼ vs ਰਨਟਾਈਮ ਰਾਜ਼

ਕੋਸ਼ਿਸ਼ ਕਰੋ ਕਿ ਜੋ ਰਾਜ਼ ਬਿਲਡ ਦੌਰਾਨ ਲੋੜੀਂਦੇ ਹਨ ਉਨ੍ਹਾਂ ਨੂੰ ਰਨਟਾਈਮ ਤੋਂ ਵੱਖ ਰੱਖੋ।

ਬਿਲਡ-ਟਾਈਮ ਰਾਜ਼ ਉਹ ਹਨ ਜਿਹੜੇ ਸਿਰਫ build ਕਦਮ ਦੌਰਾਨ ਲੋੜੀਂਦੇ ਹਨ (ਉਦਾਹਰਣ ਲਈ, ਇੱਕ ਪਰਾਈਵੇਟ ਪੈਕੇਜ ਡਾਊਨਲੋਡ ਕਰਨਾ)। ਰਨਟਾਈਮ ਰਾਜ਼ ਉਹ ਹਨ ਜਿਹੜੇ ਡਿਪਲੋਇ ਤੋਂ ਬਾਦ ਲੋੜੀਂਦੇ ਹਨ (ਉਦਾਹਰਣ: Stripe ਨੂੰ ਕਾਲ ਕਰਨਾ ਜਾਂ ਈਮੇਲ ਭੇਜਣਾ)। ਜੇ ਤੁਸੀਂ ਕੁੰਜੀਆਂ ਨੂੰ ਰਨਟਾਈਮ-ਓਨਲੀ ਰੱਖ ਸਕਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਇਹ ਘਟਾਉਂਦੇ ਹੋ ਕਿ ਉਹ ਬੰਡਲ ਵਿੱਚ ਬੇਕ ਕੀਤੀਆਂ ਜਾਂ ਆਰਟੀਫੈਕਟ ਵਿੱਚ ਕੈਸ਼ ਹੋ ਜਾਣ।

ਇੱਕ ਤੇਜ਼ ਸਵੈ-ਚੈੱਕ: ਜੇ ਰਾਜ਼ ਉਪਭੋਗਤਾ ਦੇ ਬ੍ਰਾੳਜ਼ਰ ਵਿੱਚ ਲੋੜੀਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਰਾਜ਼ ਨਹੀਂ ਹੈ। ਬ੍ਰਾੳਜ਼ਰ-ਦਿੱਖਣ ਵਾਲੀਆਂ "ਪਬਲਿਕ ਕੁੰਜੀਆਂ" ਠੀਕ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਸਰਵਰ API ਕੁੰਜੀਆਂ ਸਦਾ ਸਰਵਰ 'ਤੇ ਹੀ ਰਹਿਣ।

ਪ੍ਰੋਡਕਸ਼ਨ ਰਾਜ਼ ਕਿੱਥੇ ਰੱਖਣੇ

ਹੋਸਟਿੰਗ ਪਲੇਟਫਾਰਮ ਦੇ environment-specific secret storage ਦਾ ਉਪਯੋਗ ਕਰੋ ਤਾਂ ਜੋ dev, staging ਅਤੇ prod ਵੱਖ-ਵੱਖ ਮੁੱਲ ਰੱਖ ਸਕਣ।

ਜੇ ਤੁਸੀਂ Koder.ai ਹੋਸਟਿੰਗ ਨਾਲ ਡਿਪਲੋਏ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ env vars per environment ਵਜੋਂ ਸੈੱਟ ਕਰੋ ਬਜਾਏ ਕਿ ਕੁੰਜੀਆਂ ਨੂੰ ਕੋਡ ਜਾਂ ਕੰਫਿਗ ਫਾਇਲਾਂ ਵਿੱਚ ਪੇਸਟ ਕਰਨ ਦੇ। ਫਿਰ ਤੁਹਾਡਾ ਐਪ ਰਨਟਾਈਮ 'ਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ (ਉਦਾਹਰਣ: production ਵਿੱਚ PAYMENTS_API_KEY vs staging ਵਿੱਚ test key)।

ਪ੍ਰੋਡ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਲਈ, ਪ੍ਰੋਡ ਰਾਜ਼ ਵੇਖਣ ਜਾਂ ਬਦਲਣ ਵਾਲਿਆਂ ਨੂੰ ਸੀਮਿਤ ਕਰੋ। "ਵੀਊ ਸੀਕ੍ਰੇਟਸ" ਗਰੁੱਪ ਛੋਟਾ ਰੱਖੋ, ਅਤੇ ਜਦੋਂ ਤੁਹਾਡੇ ਟੂਲਿੰਗ ਵਿੱਚ ਸਮਰੱਥਾ ਹੋਵੇ ਤਾਂ deploy ਅਧਿਕਾਰਾਂ ਨੂੰ secret-edit ਅਧਿਕਾਰਾਂ ਤੋਂ ਵੱਖਰਾ ਕਰੋ। ਨਾਲ ਹੀ environment ਅਨੁਸਾਰ ਵੱਖਰੇ ਕੁੰਜੀਆਂ ਰੱਖੋ ਤਾਂ ਕਿ staging ਨੂੰ prod ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਨਾ ਹੋਵੇ।

ਆਮ ਗਲਤੀਆਂ (ਅਤੇ ਹਰ ਇੱਕ ਲਈ ਤੇਜ਼ ਫਿਕਸ)

ਜ਼ਿਆਦਾਤਰ ਲੀਕ ਹਰ ਰੋਜ਼ ਦੀਆਂ ਛੋਟੀਆਂ ਰਾਹਤਾਂ ਹਨ ਜੋ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਜ਼ਿਆਦਾ ਫੈਲ ਜਾਂਦੀਆਂ ਹਨ।

ਗ਼ਲਤੀ 1: ਕੋਡ ਵਿੱਚ ਕੁੰਜੀਆਂ hardcode ਕਰਨਾ (ਜਾਂ .env commit ਕਰਨਾ)

ਜੇ ਇੱਕ ਕੁੰਜੀ ਤੁਹਾਡੇ ਸੋਰਸ ਫਾਇਲਾਂ ਵਿੱਚ ਹੈ, ਤਾਂ ਇਹ backups, ਸਕ੍ਰੀਨਸ਼ਾਟ, ਸਾਂਝੇ ਜ਼ਿਪ, ਅਤੇ git ਇਤਿਹਾਸ ਵਿੱਚ ਆ ਸਕਦੀ ਹੈ।

ਫਿਕਸ:

• ਮੁੱਲ ਨੂੰ environment variable ਵਿੱਚ ਮੂਵ ਕਰੋ ਅਤੇ ਉਥੋਂ ਪੜ੍ਹੋ।
• .env ਨੂੰ ਆਪਣੇ ignore ਫਾਇਲ ਵਿੱਚ ਪਹਿਲੇ commit ਤੋਂ ਪਹਿਲਾਂ ਜੋੜੋ।
• ਜੇ ਇਹ ਪਹਿਲਾਂ ਹੀ commit ਹੋ ਚੁੱਕੀ ਹੈ, ਤਾਂ ਕੁੰਜੀ ਰੋਟੇਟ ਕਰੋ ਅਤੇ ਪੁਰਾਣੀ ਨੂੰ ਬਰਬਾਦ ਮੰਨੋ।

ਗ਼ਲਤੀ 2: ਮਦਦ ਲਈ ਪ੍ਰੰਪਟ ਵਿੱਚ ਰਾਜ਼ ਪੇਸਟ ਕਰਨਾ

ਜਦੋਂ ਤੁਸੀਂ ਅਸਲ ਕੁੰਜੀ ਇੱਕ ਚੈਟ ਵਿੱਚ ਪੇਸਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਖੋ ਜਾਂਦੇ ਹੋ ਕਿ ਉਹ ਟੈਕਸਟ ਕਿੱਥੇ ਸਾਂਝਾ ਹੋ ਰਿਹਾ ਹੈ। ਜੇ ਤੁੱਸੀਂ vibe-coding ਟੂਲ ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਲੋਭ ਹੁੰਦਾ ਹੈ ਕਿ ਸਭ ਕੁਝ ਚੈਟ ਵਿੱਚ ਦਿੱਖਾ ਦਿਓ। ਬਦਲੇ ਵਿੱਚ, ਰਾਜ਼ਾਂ ਨੂੰ PAYMENTS_API_KEY=REDACTED ਵਰਗੇ ਪਲੇਸਹੋਲਡਰ ਨਾਲ ਬਦਲੋ ਅਤੇ ਸਮੱਸਿਆ ਵਰਨਨ ਕਰੋ।

ਇੱਕ ਚੰਗੀ ਆਦਤ: error messages copy ਕਰੋ, credentials ਨਹੀਂ।

ਗ਼ਲਤੀ 3: ਇੱਕ ਹੀ ਕੁੰਜੀ ਨੂੰ ਸਭ ਕੁਝ ਅਤੇ ਹਰ ਕਿਸੇ ਲਈ ਦੁਬਾਰਾ ਵਰਤਣਾ

ਇੱਕ ਕੁੰਜੀ dev, staging ਅਤੇ prod 'ਤੇ ਵਰਤੀ ਜਾ ਰਹੀ ਹੋਏ ਤਾਂ ਇੱਕ ਲੀਕ ਵੱਡਾ ਹਾਦਸਾ ਬਣ ਸਕਦੀ ਹੈ। ਜੇ ਕਈ ਟੀਮ-ਮਿਤਰ ਇੱਕੋ ਕੁੰਜੀ ਵਰਤਦੇ ਹਨ ਤਾਂ ਤੁਹਾਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਕਿਸਨੇ ਇਸ ਨੂੰ ਵਰਤਿਆ।

ਫਿਕਸ: ਹਰ ਵਾਤਾਵਰਣ ਲਈ ਅਲੱਗ ਕੁੰਜੀਆਂ ਬਣਾਓ, ਅਤੇ ਜੇ ਤੁਹਾਡੇ ਪ੍ਰੋਵਾਈਡਰ ਸਪੋਰਟ ਕਰਦਾ ਹੈ ਤਾਂ ਵਿਅਕਤੀਗਤ ਜਾਂ ਐਪ-ਅਨੁਸਾਰ ਵੀ ਅਲੱਗ-ਅਲੱਗ ਕੁੰਜੀਆਂ ਬਣਾਓ।

ਗ਼ਲਤੀ 4: ਅਕਸਮਾਤ ਰਾਜ਼ ਲੌਗ ਕਰਨਾ

ਸਟਾਰਟਅਪ 'ਤੇ "ਸਾਰੇ config" ਪ੍ਰਿੰਟ ਕਰਨ ਦਾ ਰੁਝਾਨ ਇੱਕ ਆਮ ਫੰਸ ਹੈ। ਇਸ ਵਿੱਚ ਅਕਸਰ ਟੋਕਨ ਹੁੰਦੇ ਹਨ।

ਫਿਕਸ: ਸਿਰਫ਼ ਜ਼ਰੂਰੀ ਚੀਜ਼ਾਂ ਲੌਗ ਕਰੋ (ਉਦਾਹਰਣ ਲਈ, "Stripe key loaded: yes"), ਅਤੇ ਜੇ ਮੁੱਲ ਦਿਖਾਉਣਾ ਜਰੂਰੀ ਹੋਵੇ ਤਾਂ ਮੁੱਲ ਨੂੰ ਮਾਸਕ ਕਰੋ (ਆਖਰੀ 4 ਅੱਖਰ ਦਿਖਾਓ)।

ਉਦਾਹਰਣ: ਜੇ staging fail ਕਰ ਰਹੀ ਹੈ, ਤਾਂ ਪੂਰੀ ਕੁੰਜੀ ਪ੍ਰਿੰਟ ਨਾ ਕਰੋ। ਪ੍ਰਿੰਟ ਕਰੋ STRIPE_KEY ending in 9K2P ਤਾਂ ਜੋ ਤੁਸੀਂ ਪੁਸ਼ਟੀ ਕਰ ਸਕੋ ਕਿ ਤੁਹਾਡੀ ਸਹੀ ਕੁੰਜੀ ਡਿਪਲੋਏ ਹੋਈ ਹੈ ਬਿਨਾਂ ਇਸਨੂੰ ਬੇਨਕਾਬ ਕੀਤੇ।

ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਰਾਜ਼ਾਂ ਦੀ ਇੱਕ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ

ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਕ ਸ਼ਾਂਤ ਪਾਸ ਕਰੋ ਜੋ ਸਿਰਫ਼ ਰਾਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਦੇਵੇ।

• ਕੋਈ ਵੀ ਰਾਜ਼ ਤੁਹਾਡੇ ਰਿਪੋ ਵਿੱਚ ਨਹੀਂ (ਇਤਿਹਾਸ ਸਮੇਤ). api_key, secret, token, ਅਤੇ ਪ੍ਰੋਵਾਈਡਰ ਨਾਂ ਵਰਗੀਆਂ ਪੈਟਰਨਾਂ ਲਈ ਖੋਜ ਕਰੋ। ਜੇ ਇੱਕ ਕੁੰਜੀ ਕਦੇ git ਵਿੱਚ ਆਈ ਸੀ ਜਾਂ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ, ਤਾਂ assume ਕਰੋ ਕਿ ਇਹ ਬਰਨ ਹੋ ਚੁੱਕੀ ਹੈ ਅਤੇ ਇਸਨੂੰ ਬਦਲੋ।
• Dev, staging, ਅਤੇ prod ਵੱਖ-ਵੱਖ ਮੁੱਲ ਵਰਤਦੇ ਹਨ. ਅਲੱਗ ਕੁੰਜੀਆਂ ਨੁਕਸਾਨ ਘਟਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਟੈਸਟਿੰਗ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੀਆਂ ਹਨ।
• ਪਹੁੰਚ ਸਪੱਸ਼ਟ ਹੈ: ਕੌਣ ਵੇਖ ਸਕਦਾ ਹੈ, ਕੌਣ ਸੋਧ ਸਕਦਾ ਹੈ, ਕੌਣ ਡਿਪਲੋਏ ਕਰ ਸਕਦਾ ਹੈ. "ਵੀਊ ਸੀਕ੍ਰੇਟਸ" ਗਰੁੱਪ ਛੋਟਾ ਰੱਖੋ।
• ਤੁਹਾਡੇ ਕੋਲ ਰੋਟੇਸ਼ਨ ਯੋਜਨਾ ਅਤੇ ਹਰ ਰਾਜ਼ ਲਈ ਨਾਂਝੁੜੀ ਮਾਲਕ ਹੈ। ਹਰ ਰਾਜ਼ ਦੇ ਨਾਲ ਇੱਕ ਵਿਅਕਤੀ ਜੋੜੋ, ਟੀਮ ਨਾਮ ਨਹੀਂ।
• ਅਸਧਾਰ ਜਾਣ ਪਛਾਣ ਲਈ ਮਾਨੀਟਰਿੰਗ ਸੰਚਾਲਿਤ ਹੈ। ਪ੍ਰੋਵਾਈਡਰ ਅਲਰਟ ਲਗਾਓ ਉੱਚ ਉਪਯੋਗਤਾ, ਫੇਲਡ auth storms, ਅਤੇ ਬਜਟ ਸੀਮਾਵਾਂ ਲਈ।

ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਣ: ਜੇ ਤੁਹਾਡਾ ਐਪ ਇੱਕ ਭੁਗਤਾਨ API ਅਤੇ ਇੱਕ ਈਮੇਲ API ਵਰਤਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ dev, staging, ਅਤੇ prod ਲਈ ਦੋ ਅਲੱਗ ਕੁੰਜੀਆਂ ਹੋਣ ਚਾਹੀਦੀਆਂ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਲਈ ਇੱਕ ਸਪੱਸ਼ਟ ਮਾਲਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਡਿਪਲੋਏ ਕਰ ਰਹੇ ਹੋ (ਆਪਣੀ ਹੋਸਟਿੰਗ ਸੈਟਅਪ ਜਾਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਰਾਹੀਂ), ਤਾਂ ਸਹੀ env vars ਨੂੰ ਸਹੀ ਵਾਤਾਵਰਣ ਵਿੱਚ ਮੈਪ ਕਰੋ — ਨਾ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਪ੍ਰੰਪਟ, ਕੋਡ, ਜਾਂ ਰਿਪੋ ਵਿੱਚ ਕਾਪੀ ਕਰੋ।

ਉਦਾਹਰਣ ਸੱਜੇ-ਹਾਲਾਤ ਅਤੇ ਤੁਹਾਡੇ ਬਿਲਡ ਲਈ ਅੱਗੇ ਦੇ ਕਦਮ

Maya ਇੱਕ ਗੈਰ-ਤਕਨੀਕੀ ਫਾਊਂਡਰ ਹੈ ਜੋ ਇੱਕ ਸਧਾਰਨ ਵੈੱਬ ਐਪ ਬਣਾ ਰਹੀ ਹੈ: ਉਪਭੋਗਤਾ ਇੱਕ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਲਈ ਭੁਗਤਾਨ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਐਪ ਰਸੀਦਾਂ ਅਤੇ password resets ਈਮੇਲ ਕਰਦੀ ਹੈ। ਉਹ ਆਪਣੇ ਪ੍ਰੰਪਟ ਅਤੇ ਰਿਪੋ ਨੂੰ ਸਾਫ਼ ਰੱਖਦੀ ਹੈ ਇਸ ਤਰ੍ਹਾਂ ਕਿ ਰਾਜ਼ settings ਦੇ ਤੌਰ 'ਤੇ ਕੋਡ ਤੋਂ ਬਾਹਰ ਰਹਿਣ, ਜੋ ਰਨਟਾਈਮ 'ਤੇ environment variables ਰਾਹੀਂ inject ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

ਇਥੇ ਕੁਝ ਪ੍ਰਯੋਗੀ env vars ਹਨ ਜੋ ਉਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੀ ਹੈ (ਨਾਂ ਹਰ ਜਗ੍ਹਾ ਇੱਕੋ ਰਹਿੰਦੇ ਹਨ; ਸਿਰਫ ਮੁੱਲ बदलਦੇ ਹਨ):

• APP_ENV = development / staging / production
• APP_BASE_URL = http://localhost:3000 / https://staging.example.com / https://example.com
• PAYMENTS_PROVIDER_SECRET_KEY = test key (dev) / test key (staging) / live key (prod)
• EMAIL_PROVIDER_API_KEY = sandbox key (dev) / restricted key (staging) / full key (prod)
• DATABASE_URL = local DB (dev) / staging DB (staging) / production DB (prod)

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

ਹੁਣ ਇੱਕ ਹਕੀਕਤੀ ਰੋਟੇਸ਼ਨ ਘਟਨਾ: ਇੱਕ ਕਰੈਕਟਰ ਛੱਡ ਕੇ ਚਲਾ ਗਿਆ ਜਿਸਨੂੰ ਪਹੁੰਚ ਸੀ। Maya ਮਨਦੀ ਹੈ ਕਿ ਪੁਰਾਣੀਆਂ ਕੁੰਜੀਆਂ ਨਾਜ਼ੁਕ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਉਹ ਭੁਗਤਾਨ ਅਤੇ ਈਮੇਲ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਨਵੀਆਂ ਕੁੰਜੀਆਂ ਬਣਾਉਂਦੀ ਹੈ, ਫਿਰ ਹਰ ਵਾਤਾਵਰਣ ਲਈ environment ਮੁੱਲ ਅੱਪਡੇਟ ਕਰਦੀ ਹੈ। ਉਹ ਪਹਿਲਾਂ production ਰੋਟੇਟ ਕਰਦੀ ਹੈ ਇੱਕ ਠੰਢੇ ਸਮੇਂ ਦੌਰਾਨ, signups, payments ਅਤੇ emails verify ਕਰਦੀ ਹੈ, ਅਤੇ ਫਿਰ staging ਅਤੇ dev ਰੋਟੇਟ ਕਰਦੀ ਹੈ। ਜੇ ਕੁਝ ਟੁੱਟਦਾ ਹੈ, ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਪਿਛਲੇ ਜਾਣੂ-ਚੰਗੇ ਕਨਫਿਗ ਨੂੰ ਰੀਸਟੋਰ ਕਰਕੇ rollback ਕਰ ਲੈਂਦੀ ਹੈ।

ਆਗੇ ਦੇ ਕਦਮ ਜੋ ਮਾਮਲੇ ਨੂੰ ਬਾਦ ਵਿੱਚ ਗੁੰਝਲਦਾਰ ਨਹੀਂ ਬਣਾਉਣਗੇ:

ਇੱਕ-ਪੰਨੇ ਦਾ "Env Var List" ਲਿਖੋ (ਨਾਂ, ਇਹ ਕਿਸ ਲਈ ਹੈ, ਕਿੱਥੇ ਸੈਟ ਹੈ, ਅਤੇ ਕੌਣ ਪਹੁੰਚ ਰੱਖਦਾ ਹੈ)। ਮਹੀਨੇ ਵਿੱਚ ਇੱਕ 10-ਮਿੰਟ ਦੀ ਸਮੀਖਿਆ ਕੈਲੇਂਡਰ 'ਤੇ ਰੱਖੋ ਤਾਂ ਕਿ ਬੇਕਾਰ ਕੁੰਜੀਆਂ ਹਟਾਈਆਂ ਜਾ ਸਕਣ ਅਤੇ ਜੋ ਵੀ ਜੋਖਮ ਵੱਧ ਹੈ ਉਹ ਰੋਟੇਟ ਕੀਤਾ ਜਾ ਸਕੇ।

ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ Koder.ai (koder.ai) ਨਾਲ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਸੰਗਠਿਤ ਰੱਖਣ ਵਿੱਚ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਡਿਪਲੋਏਮੈਂਟ ਅਤੇ environment settings ਇਕੱਠੇ ਪ੍ਰਬੰਧ ਕਰ ਸਕਦੇ ਹੋ। snapshots ਅਤੇ rollback ਵੀ ਮਦਦਗਾਰ ਹਨ ਜਦੋਂ ਕੋਈ ਕਾਨਫ਼ਿਗ ਬਦਲਾਅ outage ਕਰ ਦੇਵੇ ਅਤੇ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬਹਾਲੀ ਦੀ ਲੋੜ ਹੋਵੇ।