ਬਿਲਡਕਿੱਟ: ਡੌਕਰ ਦਾ ਲੁਕਿਆ ਹੋਇਆ ਰਤਨ ਜੋ ਲਗਭਗ ਕੁਝ ਵੀ ਬਣਾ ਸਕਦਾ ਹੈ

ਬਿਲਡਕਿੱਟ: ਡੌਕਰ ਦਾ ਲੁਕਿਆ ਹੋਇਆ ਰਤਨ ਜੋ ਲਗਭਗ ਕੁਝ ਵੀ ਬਣਾ ਸਕਦਾ ਹੈ

ਜ਼ਿਆਦਾਤਰ ਡਿਵੈਲਪਰ ਡੌਕਰ ਨੂੰ ਕੰਟੇਨਰ ਰਨਟਾਈਮ ਵਜੋਂ ਜਾਣਦੇ ਹਨ ਜਿਸ ਨੇ ਬਦਲ ਦਿੱਤਾ ਕਿ ਸੌਫਟਵੇਅਰ ਕਿਵੇਂ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ। ਹਰ ਆਧੁਨਿਕ ਡੌਕਰ ਬਿਲਡ - ਬਿਲਡਕਿੱਟ, ਅਗਲੀ ਪੀੜ੍ਹੀ ਦਾ ਬਿਲਡ ਸਿਸਟਮ ਜੋ ਕਿ ਵਰਜਨ 18.09 ਤੋਂ ਡੌਕਰ ਨਾਲ ਸ਼ਿਪਿੰਗ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਡੌਕਰ 23.0 ਵਿੱਚ ਡਿਫੌਲਟ ਬੈਕਐਂਡ ਬਣ ਗਿਆ ਹੈ, ਦੇ ਇੰਜਣ ਬਾਰੇ ਬਹੁਤ ਘੱਟ ਲੋਕ ਜਾਣਦੇ ਹਨ। ਜਦੋਂ ਕਿ ਇੰਜਨੀਅਰ ਕੁਬਰਨੇਟਸ ਕੌਂਫਿਗਰੇਸ਼ਨਾਂ ਅਤੇ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਪੈਟਰਨਾਂ ਬਾਰੇ ਬੇਅੰਤ ਬਹਿਸ ਕਰਦੇ ਹਨ, ਬਿਲਡਕਿੱਟ ਲਗਾਤਾਰ DevOps ਈਕੋਸਿਸਟਮ ਵਿੱਚ ਸਭ ਤੋਂ ਸ਼ਕਤੀਸ਼ਾਲੀ, ਲਚਕਦਾਰ ਬਿਲਡ ਸਿਸਟਮਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਵਿਕਸਤ ਹੋ ਰਿਹਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਤੇਜ਼ ਡੌਕਰ ਬਿਲਡ ਦੇ ਰੂਪ ਵਿੱਚ ਸਮਝ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਮੇਜ਼ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਰੱਥਾ ਛੱਡ ਰਹੇ ਹੋ। ਉੱਚ-ਥਰੂਪੁੱਟ CI/CD ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਚਲਾਉਣ ਵਾਲੀਆਂ ਕੰਪਨੀਆਂ ਨੇ ਬਿਲਡਕਿੱਟ ਅਸਲ ਵਿੱਚ ਕੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ ਇਹ ਸਮਝ ਕੇ ਬਿਲਡ ਸਮੇਂ ਵਿੱਚ 50-70% ਦੀ ਕਟੌਤੀ ਕੀਤੀ ਹੈ - ਅਤੇ ਇਹ ਸਿਰਫ ਸ਼ੁਰੂਆਤ ਹੈ।

ਕੀ ਚੀਜ਼ ਬਿਲਡਕਿੱਟ ਨੂੰ ਕਲਾਸਿਕ ਬਿਲਡਰ ਤੋਂ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਵੱਖਰਾ ਬਣਾਉਂਦਾ ਹੈ

ਮੂਲ ਡੌਕਰ ਬਿਲਡ ਇੰਜਣ ਨੇ ਡੌਕਰਫਾਈਲ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਕ੍ਰਮਵਾਰ, ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਲੇਅਰ ਨੂੰ ਲਾਗੂ ਕੀਤਾ, ਇਸ ਬਾਰੇ ਕੋਈ ਜਾਗਰੂਕਤਾ ਨਹੀਂ ਕਿ ਸਮਾਂਤਰ ਵਿੱਚ ਕੀ ਕੰਮ ਸੁਰੱਖਿਅਤ ਰੂਪ ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ। ਬਿਲਡਕਿੱਟ ਉਸ ਲੀਨੀਅਰ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਮਾਡਲ ਨੂੰ ਡਾਇਰੈਕਟਡ ਐਸੀਕਲਿਕ ਗ੍ਰਾਫ (DAG) ਨਾਲ ਬਦਲਦਾ ਹੈ — ਇੱਕ ਨਿਰਭਰਤਾ ਗ੍ਰਾਫ ਜੋ ਸਮਝਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਬਿਲਡ ਸਟੈਪਸ ਇੱਕ ਦੂਜੇ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਅਤੇ ਕਿਹੜੇ ਨਹੀਂ। ਸੁਤੰਤਰ ਪੜਾਅ ਇੱਕੋ ਸਮੇਂ ਚੱਲਦੇ ਹਨ, ਨਾ ਵਰਤੇ ਗਏ ਪੜਾਵਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਪੂਰੀ ਬਿਲਡ ਤੁਹਾਨੂੰ ਸਹੀ ਕ੍ਰਮ ਵਿੱਚ ਪਾਠ ਕਰਨ ਵਾਲੇ ਕਦਮਾਂ ਦੇ ਇੱਕ ਜ਼ਰੂਰੀ ਕ੍ਰਮ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਕੀ ਚਾਹੁੰਦੇ ਹੋ ਦਾ ਇੱਕ ਘੋਸ਼ਣਾਤਮਕ ਵਰਣਨ ਬਣ ਜਾਂਦਾ ਹੈ।

ਇਸ ਆਰਕੀਟੈਕਚਰਲ ਸ਼ਿਫਟ ਦੇ ਅਮਲੀ ਨਤੀਜੇ ਹਨ ਜੋ ਗਤੀ ਤੋਂ ਪਰੇ ਹਨ। ਜਦੋਂ ਇੱਕ ਮਲਟੀ-ਸਟੇਜ ਡੌਕਰਫਾਈਲ ਇੱਕ ਪੜਾਅ ਵਿੱਚ ਇੱਕ ਗੋ ਬਾਇਨਰੀ ਨੂੰ ਕੰਪਾਇਲ ਕਰਦੀ ਹੈ, ਦੂਜੇ ਵਿੱਚ Node.js ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਤੀਜੇ ਵਿੱਚ ਇੱਕ ਉਤਪਾਦਨ ਚਿੱਤਰ ਨੂੰ ਇਕੱਠਾ ਕਰਦੀ ਹੈ, ਤਾਂ BuildKit ਪਹਿਲੇ ਦੋ ਪੜਾਵਾਂ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਚਲਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਬਿਲਡ ਜੋ ਪਹਿਲਾਂ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ CI ਦੌੜਾਕ 'ਤੇ ਚਾਰ ਮਿੰਟ ਲੈਂਦਾ ਸੀ ਹੁਣ ਨੱਬੇ ਸਕਿੰਟਾਂ ਤੋਂ ਘੱਟ ਵਿੱਚ ਪੂਰਾ ਹੋ ਜਾਂਦਾ ਹੈ। Stripe, Shopify, ਅਤੇ ਹੋਰ ਉੱਚ-ਸਕੇਲ ਇੰਜਨੀਅਰਿੰਗ ਟੀਮਾਂ ਦੇ ਸਕੋਰਾਂ ਨੇ ਆਪਣੇ ਅੰਦਰੂਨੀ ਟੂਲਿੰਗ ਪੂਰਵ-ਅਨੁਮਾਨਾਂ ਵਿੱਚ ਸਮਾਨ ਲਾਭਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕੀਤਾ ਹੈ। ਡੀਏਜੀ ਮਾਡਲ ਦਾ ਇਹ ਵੀ ਮਤਲਬ ਹੈ ਕਿ ਬਿਲਡਕਿੱਟ ਬਹੁਤ ਹੀ ਸਟੀਕ ਬਿਲਡ ਮੈਟਾਡੇਟਾ ਤਿਆਰ ਕਰ ਸਕਦੀ ਹੈ — ਪ੍ਰੋਵੇਨੈਂਸ ਤਸਦੀਕ ਅਤੇ ਸਾੱਫਟਵੇਅਰ ਬਿਲ ਆਫ਼ ਮਟੀਰੀਅਲ (SBOM) ਜਨਰੇਸ਼ਨ ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਈ ਇੱਕ ਬੁਨਿਆਦ ਜੋ ਸਪਲਾਈ ਚੇਨ ਸੁਰੱਖਿਆ ਲਈ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹਨ।

ਕੈਸ਼ ਅਵੈਧਤਾ ਦੇ ਕੰਮ ਕਰਨ ਦੇ ਤਰੀਕੇ ਵਿੱਚ ਇੱਕ ਸੰਕਲਪਿਕ ਤਬਦੀਲੀ ਵੀ ਹੈ। ਕਲਾਸਿਕ ਬਿਲਡਰ ਨੇ ਕਿਸੇ ਵੀ ਬਦਲੇ ਹੋਏ ਨਿਰਦੇਸ਼ ਦੇ ਹੇਠਾਂ ਹਰ ਪਰਤ ਨੂੰ ਅਯੋਗ ਕਰ ਦਿੱਤਾ। ਬਿਲਡਕਿੱਟ ਹਰੇਕ ਇਨਪੁਟ 'ਤੇ ਸਮੱਗਰੀ ਹੈਸ਼ਾਂ ਨੂੰ ਟ੍ਰੈਕ ਕਰਦੀ ਹੈ, ਇਸਲਈ ਇੱਕ ਡੌਕਰਫਾਈਲ ਵਿੱਚ ਇੱਕ ਟਿੱਪਣੀ ਨੂੰ ਬਦਲਣਾ ਇੱਕ ਕੈਸ਼ ਐਂਟਰੀ ਨੂੰ ਉਡਾ ਨਹੀਂ ਦਿੰਦਾ ਜੋ ਤੀਹ ਮਿੰਟਾਂ ਦੇ ਸੰਕਲਨ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਤੁਹਾਡਾ ਬਿਲਡ ਕੈਸ਼ ਤੁਹਾਡੀ ਇੰਜਨੀਅਰਿੰਗ ਟੀਮ ਲਈ ਪੰਜ-ਮਿੰਟ ਅਤੇ ਚਾਲੀ-ਮਿੰਟ ਫੀਡਬੈਕ ਲੂਪ ਵਿੱਚ ਫਰਕ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਸ਼ੁੱਧਤਾ ਉਸ ਤੋਂ ਕਿਤੇ ਵੱਧ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ ਜੋ ਸ਼ੁਰੂ ਵਿੱਚ ਜਾਪਦੀ ਹੈ।

ਮਲਟੀ-ਪਲੇਟਫਾਰਮ ਬਿਲਡਸ: ਇੱਕ ਕਮਾਂਡ, ਹਰ ਆਰਕੀਟੈਕਚਰ

ਬਿਲਡਕਿੱਟ ਦਾ --ਪਲੇਟਫਾਰਮ ਫਲੈਗ ਅਤੇ QEMU ਏਕੀਕਰਣ ਇੱਕ ਸਿੰਗਲ ਕਮਾਂਡ ਵਿੱਚ ਇੱਕ ਦਰਦਨਾਕ ਮਲਟੀ-ਸਿਸਟਮ ਤਾਲਮੇਲ ਸਮੱਸਿਆ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ। docker buildx build --platform linux/amd64,linux/arm64,linux/arm/v7. ਨੂੰ ਚਲਾਉਣਾ ਇੱਕ ਸਿੰਗਲ ਬਿਲਡ ਇਨਵੋਕੇਸ਼ਨ ਦੇ ਸਮਾਨਾਂਤਰ ਤਿੰਨ ਉਤਪਾਦਨ-ਤਿਆਰ ਚਿੱਤਰ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਸਮਰੱਥਾ ਨਾਜ਼ੁਕ ਬਣ ਗਈ ਹੈ ਕਿਉਂਕਿ ਉਦਯੋਗ ARM ਵੱਲ ਬਦਲਦਾ ਹੈ — AWS Graviton3 ਉਦਾਹਰਨਾਂ ਵੈੱਬ ਸਰਵਿੰਗ ਅਤੇ ਡਾਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਵਰਗੇ ਵਰਕਲੋਡਾਂ 'ਤੇ ਲਗਾਤਾਰ 40% ਬਿਹਤਰ ਕੀਮਤ-ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ Apple Silicon ਨੇ ਲੱਖਾਂ ਇੰਜੀਨੀਅਰਾਂ ਲਈ ARM ਨੂੰ ਡਿਫੌਲਟ ਵਿਕਾਸ ਮਸ਼ੀਨ ਬਣਾ ਦਿੱਤਾ ਹੈ।

ਬਿਲਡਕਿਟ ਦੇ ਮਲਟੀ-ਪਲੇਟਫਾਰਮ ਸਪੋਰਟ ਦੇ ਪਰਿਪੱਕ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ, ਵੱਖ-ਵੱਖ ਆਰਕੀਟੈਕਚਰ ਲਈ ਵੱਖਰੀਆਂ ਬਿਲਡ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਕਾਇਮ ਰੱਖਣਾ ਇੱਕ ਅਸਲ ਲਾਗਤ ਕੇਂਦਰ ਸੀ। ਟੀਮਾਂ ਨੇ ਜਾਂ ਤਾਂ ਮਲਟੀਪਲ ਡੌਕਰਫਾਈਲਾਂ ਬਣਾਈਆਂ, ਵੱਖਰੇ-ਆਰਕੀਟੈਕਟਡ ਦੌੜਾਕਾਂ 'ਤੇ ਵੱਖਰੀਆਂ CI ਪਾਈਪਲਾਈਨਾਂ ਚਲਾਈਆਂ, ਜਾਂ ਹਰ ਜਗ੍ਹਾ x86 ਚਿੱਤਰ ਭੇਜੇ ਅਤੇ ARM ਬੁਨਿਆਦੀ ਢਾਂਚੇ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਜੁਰਮਾਨਾ ਅਦਾ ਕੀਤਾ। ਬਿਲਡਕਿੱਟ ਦੇ ਨਾਲ, ਤੁਸੀਂ ਆਪਣੇ ਬਿਲਡ ਨੂੰ ਇੱਕ ਵਾਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹੋ ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਆਰਕੀਟੈਕਚਰ-ਵਿਸ਼ੇਸ਼ ਸੰਕਲਨ ਨੂੰ ਪਾਰਦਰਸ਼ੀ ਢੰਗ ਨਾਲ ਸੰਭਾਲਣ ਦਿੰਦੇ ਹੋ। ਜੰਗਾਲ ਪ੍ਰੋਜੈਕਟ ਜਿਨ੍ਹਾਂ ਲਈ ਕਰਾਸ-ਕੰਪਾਈਲੇਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, CGO ਨਿਰਭਰਤਾ ਵਾਲੇ ਗੋ ਪ੍ਰੋਜੈਕਟ, C ਐਕਸਟੈਂਸ਼ਨਾਂ ਵਾਲੇ ਪਾਇਥਨ ਪੈਕੇਜ — ਬਿਲਡਕਿੱਟ ਤੁਹਾਨੂੰ ਹਰੇਕ ਟੀਚਾ ਪਲੇਟਫਾਰਮ ਦੇ ਵੇਰਵਿਆਂ ਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਤੋਂ ਬਿਨਾਂ ਇਮੂਲੇਸ਼ਨ ਲੇਅਰ ਨੂੰ ਹੈਂਡਲ ਕਰਦੀ ਹੈ।

ਇੱਥੇ ਵਿਹਾਰਕ ਵਪਾਰਕ ਮੁੱਲ ਮਾਪਣਯੋਗ ਹੈ। AWS Graviton ਉਦਾਹਰਨਾਂ 'ਤੇ 200 ਕੰਟੇਨਰਾਂ ਨੂੰ ਚਲਾਉਣ ਵਾਲੀ ਟੀਮ $0.04 ਪ੍ਰਤੀ vCPU-ਘੰਟੇ ਦੇ ਮੁਕਾਬਲੇ ਬਰਾਬਰ x86 ਉਦਾਹਰਨ $0.056 ਪ੍ਰਤੀ vCPU-ਘੰਟੇ 'ਤੇ ਲਗਭਗ $11,520 ਸਾਲਾਨਾ ਪ੍ਰਤੀ 100 vCPU ਦੀ ਬਚਤ ਕਰਦੀ ਹੈ — ਬਿਲਕੁਲ ਸਹੀ ਆਰਕੀਟ ਦੀ ਚੋਣ ਕਰਨ ਤੋਂ। ਮੁੜ-ਇੰਜੀਨੀਅਰਿੰਗ ਦੇ ਯਤਨਾਂ ਤੋਂ ਬਿਨਾਂ ਉਸ ਚੋਣ ਨੂੰ ਪਹੁੰਚਯੋਗ ਬਣਾਉਣਾ ਬਿਲਕੁਲ ਉਸੇ ਕਿਸਮ ਦਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਅਨੁਕੂਲਨ ਹੈ ਜੋ ਆਪਣੇ ਲਈ ਤੁਰੰਤ ਭੁਗਤਾਨ ਕਰਦਾ ਹੈ।

ਚਿੱਤਰ ਪਰਤਾਂ ਵਿੱਚ ਲੀਕ ਕੀਤੇ ਬਿਨਾਂ ਗੁਪਤ ਪ੍ਰਬੰਧਨ

ਸਭ ਤੋਂ ਘੱਟ ਪ੍ਰਸ਼ੰਸਾਯੋਗ ਬਿਲਡਕਿੱਟ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਇਸਦਾ ਸੀਕਰੇਟਸ API ਹੈ। ਕਲਾਸਿਕ ਡੌਕਰ ਬਿਲਡਰ ਕੋਲ ਉਹਨਾਂ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਦੇ ਬਿਨਾਂ ਬਿਲਡ ਵਿੱਚ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨੂੰ ਪਾਸ ਕਰਨ ਦਾ ਕੋਈ ਸਾਫ਼ ਤਰੀਕਾ ਨਹੀਂ ਸੀ ਜੋ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਇੱਕ ਚਿੱਤਰ ਪਰਤ ਵਿੱਚ ਖਤਮ ਹੁੰਦਾ ਹੈ। ਡਿਵੈਲਪਰਾਂ ਨੇ ਮਲਟੀ-ਸਟੇਜ ਬਿਲਡਸ, ARG ਨਿਰਦੇਸ਼ਾਂ, ਅਤੇ ਧਿਆਨ ਨਾਲ ਆਰਡਰਿੰਗ ਨਾਲ ਇਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਕੰਮ ਕੀਤਾ — ਪਰ ਗਲਤੀ ਨਾਲ ਇੱਕ API ਕੁੰਜੀ ਜਾਂ ਪ੍ਰਾਈਵੇਟ SSH ਕੁੰਜੀ ਨੂੰ ਇੱਕ ਭੇਜੇ ਗਏ ਚਿੱਤਰ ਵਿੱਚ ਬੇਕ ਕਰਨ ਦਾ ਜੋਖਮ ਅਸੁਵਿਧਾਜਨਕ ਤੌਰ 'ਤੇ ਉੱਚਾ ਰਿਹਾ। ਸੁਰੱਖਿਆ ਸਕੈਨਰ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਜਨਤਕ ਰਜਿਸਟਰੀਆਂ ਲਈ ਪ੍ਰਕਾਸ਼ਿਤ ਕੰਟੇਨਰ ਚਿੱਤਰਾਂ ਵਿੱਚ ਹਾਰਡਕੋਡ ਕੀਤੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਲੱਭਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਲੀਕ ਬਿਲਡਾਂ ਦੇ ਦੌਰਾਨ ਬੇਢੰਗੇ ਗੁਪਤ ਪ੍ਰਬੰਧਨ ਲਈ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਟਰੇਸ ਕਰਦੇ ਹਨ।

ਬਿਲਡਕਿੱਟ ਦਾ --secret ਫਲੈਗ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਨੂੰ ਇੱਕ ਅਸਥਾਈ ਫਾਈਲ ਸਿਸਟਮ ਮਾਰਗ ਵਜੋਂ ਬਿਲਡ ਵਾਤਾਵਰਣ ਵਿੱਚ ਮਾਊਂਟ ਕਰਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਖਾਸ RUN ਹਦਾਇਤਾਂ ਦੀ ਮਿਆਦ ਲਈ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ ਜਿਸਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਕਦੇ ਵੀ ਕਿਸੇ ਚਿੱਤਰ ਪਰਤ ਨੂੰ ਛੂਹਦਾ ਨਹੀਂ ਹੈ। ਇੱਕ ਡੌਕਰਫਾਈਲ ਹਿਦਾਇਤ ਜਿਵੇਂ ਕਿ RUN --mount=type=secret,id=npmrc cat /run/secrets/npmrc > ~/.npmrc && npm install ਬਿਲਡ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਨਿੱਜੀ npm ਕ੍ਰੀਡੈਂਸ਼ੀਅਲਾਂ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਉਹਨਾਂ ਕ੍ਰੀਡੈਂਸ਼ੀਅਲਾਂ ਦੇ ਜੋ ਕਦੇ ਅੰਤਿਮ ਚਿੱਤਰ ਜਾਂ ਕਿਸੇ ਵਿਚਕਾਰਲੀ ਪਰਤ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। ਇਹੀ ਪੈਟਰਨ PyPI ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ, Maven ਸੈਟਿੰਗਾਂ, ਪ੍ਰਾਈਵੇਟ Git ਰਿਪੋਜ਼ਟਰੀਆਂ ਲਈ SSH ਕੁੰਜੀਆਂ, ਅਤੇ ਤੁਹਾਡੀ ਬਿਲਡ ਪ੍ਰਕਿਰਿਆ ਲਈ ਲੋੜੀਂਦੀ ਕੋਈ ਹੋਰ ਸੰਵੇਦਨਸ਼ੀਲ ਸਮੱਗਰੀ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ।

ਸਾਫਟਵੇਅਰ ਬਣਾਉਣ ਵਾਲੀਆਂ ਟੀਮਾਂ ਲਈ ਜੋ ਨਿਯੰਤ੍ਰਿਤ ਉਦਯੋਗਾਂ ਨੂੰ ਛੂਹਦੀਆਂ ਹਨ — ਹੈਲਥਕੇਅਰ ਪਲੇਟਫਾਰਮ, ਫਿਨਟੇਕ ਉਤਪਾਦ, HR ਸੌਫਟਵੇਅਰ — "ਪ੍ਰਮਾਣ ਪੱਤਰ ਚਿੱਤਰ ਵਿੱਚ ਹੋ ਸਕਦੇ ਹਨ" ਅਤੇ "ਪ੍ਰਮਾਣ ਪੱਤਰ ਸੰਭਵ ਤੌਰ 'ਤੇ ਚਿੱਤਰ ਵਿੱਚ ਨਹੀਂ ਹੋ ਸਕਦੇ" ਵਿਚਕਾਰ ਅੰਤਰ ਸੁਰੱਖਿਆ ਆਡਿਟ ਪਾਸ ਕਰਨ ਅਤੇ ਖੋਜਾਂ ਨੂੰ ਸੁਧਾਰਨ ਲਈ ਤਿੰਨ ਹਫ਼ਤੇ ਖਰਚ ਕਰਨ ਵਿੱਚ ਅੰਤਰ ਹੈ। ਮੇਵੇਜ਼ ਵਰਗੇ ਪਲੇਟਫਾਰਮ, ਜੋ ਕਿ ਪੇਰੋਲ, ਐਚਆਰ, ਅਤੇ ਇਨਵੌਇਸਿੰਗ ਵਰਗੇ ਉਦਯੋਗਾਂ ਵਿੱਚ 138,000 ਤੋਂ ਵੱਧ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਪਾਵਰ ਬਿਜ਼ਨਸ ਸੰਚਾਲਨ ਕਰਦੇ ਹਨ, ਉਹਨਾਂ ਦੇ ਬਿਲਡ ਅਤੇ ਡਿਪਲਾਇਮੈਂਟ ਪਾਈਪਲਾਈਨਾਂ ਵਿੱਚ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਸਾਬਤ ਹੋਣ ਯੋਗ ਸੁਰੱਖਿਆ ਸਥਿਤੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਗਾਹਕ ਉਹਨਾਂ ਦੇ ਸੰਵੇਦਨਸ਼ੀਲ ਵਿੱਤੀ ਅਤੇ ਅਮਲੇ ਦੇ ਡੇਟਾ ਨੂੰ ਵਧਾ ਸਕਣ।

ਕੈਸ਼ ਨਿਰਯਾਤ: CI ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਅਸਲ ਵਿੱਚ ਤੇਜ਼ ਬਣਾਉਣਾ

ਸੀਆਈ ਪਾਈਪਲਾਈਨਾਂ ਉਹ ਹਨ ਜਿੱਥੇ ਬਿਲਡ ਪ੍ਰਦਰਸ਼ਨ ਸਭ ਤੋਂ ਵੱਧ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਅਤੇ ਜਿੱਥੇ ਡਿਫੌਲਟ ਡੌਕਰ ਬਿਲਡ ਅਨੁਭਵ ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਦੁਖਦਾਈ ਰਿਹਾ ਹੈ। ਤਾਜ਼ੇ CI ਦੌੜਾਕ ਆਮ ਤੌਰ 'ਤੇ ਖਾਲੀ ਕੈਚਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ, ਭਾਵ ਹਰ ਪਾਈਪਲਾਈਨ ਰਨ ਸਕ੍ਰੈਚ ਤੋਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਦੁਬਾਰਾ ਕੰਪਾਈਲ ਕਰਦੀ ਹੈ। ਸੈਂਕੜੇ ਮਾਵੇਨ ਨਿਰਭਰਤਾਵਾਂ, ਇੱਕ ਜੰਗਾਲ ਪ੍ਰੋਜੈਕਟ, ਜਾਂ ਭਾਰੀ ਮੂਲ ਐਕਸਟੈਂਸ਼ਨਾਂ ਵਾਲੀ ਪਾਈਥਨ ਐਪਲੀਕੇਸ਼ਨ ਵਾਲੀ ਇੱਕ Java ਸੇਵਾ ਲਈ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬਿਲਡ ਟਾਈਮ ਸਕਿੰਟਾਂ ਦੀ ਬਜਾਏ ਮਿੰਟਾਂ ਵਿੱਚ ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ। ਹੌਲੀ CI ਦੀ ਕਾਰੋਬਾਰੀ ਲਾਗਤ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ — ਘਟੀ ਹੋਈ ਤੈਨਾਤੀ ਬਾਰੰਬਾਰਤਾ, ਲੰਬੇ ਫੀਡਬੈਕ ਲੂਪਸ, ਅਤੇ ਇੰਜਨੀਅਰ ਵਿਹਲੇ ਬੈਠੇ ਹੋਏ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਮਿਲਾਉਣ ਅਤੇ ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਪੂਰਾ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹਨ।

ਬਿਲਡਕਿੱਟ ਦੀ ਕੈਸ਼ ਐਕਸਪੋਰਟ ਵਿਸ਼ੇਸ਼ਤਾ ਇਸ ਨੂੰ ਨਿਰਯਾਤ ਯੋਗ ਕੈਸ਼ ਮੈਨੀਫੈਸਟਸ ਨਾਲ ਹੱਲ ਕਰਦੀ ਹੈ। --cache-to type=registry,ref=myregistry/myapp:cache ਅਤੇ --cache-from type=registry,ref=myregistry/myapp:cache ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, BuildKit ਇੱਕ ਵਿਸਤ੍ਰਿਤ ਕੈਸ਼ ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਰਜਿਸਟਰੀ ਵਿੱਚ ਪੁਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਹਰੇਕ ਬਿਲਡ ਦੇ ਅਗਲੇ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਕੈਸ਼ ਸਮੱਗਰੀ ਨੂੰ ਸੰਬੋਧਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਇਸਲਈ ਸਿਰਫ਼ ਅਸਲ ਵਿੱਚ ਬਦਲੀਆਂ ਗਈਆਂ ਪਰਤਾਂ ਹੀ ਮੁੜ ਪ੍ਰਾਪਤ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। GitHub ਐਕਸ਼ਨਜ਼, GitLab CI, ਅਤੇ CircleCI ਵਿੱਚ ਇਸ ਪੈਟਰਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀਆਂ ਟੀਮਾਂ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਪਾਈਪਲਾਈਨ ਦੇ ਸਮੇਂ ਨੂੰ ਪੰਦਰਾਂ ਮਿੰਟਾਂ ਤੋਂ ਬਾਅਦ ਦੀਆਂ ਦੌੜਾਂ 'ਤੇ ਤਿੰਨ ਤੋਂ ਘੱਟ ਤੱਕ ਘਟਾਉਂਦੀਆਂ ਹਨ। ਐਡਵਾਂਸਡ ਡੌਕਰ ਬਿਲਡ ਵਰਕਫਲੋਜ਼ 'ਤੇ GitHub ਦਾ ਆਪਣਾ ਦਸਤਾਵੇਜ਼ ਬਿਲਕੁਲ ਇਸ ਕਾਰਨ ਕਰਕੇ ਇਸ ਪੈਟਰਨ ਦੀ ਜ਼ੋਰਦਾਰ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹੈ।

ਸਭ ਤੋਂ ਤੇਜ਼ ਬਿਲਡ ਉਹ ਹੈ ਜਿਸ ਨੂੰ ਤੁਹਾਨੂੰ ਦੁਬਾਰਾ ਕਦੇ ਨਹੀਂ ਚਲਾਉਣਾ ਪੈਂਦਾ। ਬਿਲਡਕਿੱਟ ਦਾ ਲੇਅਰਡ, ਕੰਟੈਂਟ-ਐਡਰੈੱਸਡ ਕੈਸ਼ ਸਿਸਟਮ ਸਿਰਫ ਬਿਲਡਾਂ ਨੂੰ ਤੇਜ਼ ਨਹੀਂ ਕਰਦਾ — ਇਹ "ਬਿਲਡ" ਦੇ ਪੂਰੇ ਸੰਕਲਪ ਨੂੰ ਚੁਸਤ ਬਣਾਉਂਦਾ ਹੈ, ਦੁਹਰਾਉਣ ਵਾਲੇ ਸੰਕਲਨ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੀ ਬਦਲਿਆ ਹੈ ਦੇ ਇੱਕ ਵਾਧੇ ਵਾਲੇ ਅੰਤਰ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।

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

ਬਿਲਡਕਿੱਟ ਫਰੰਟੈਂਡਸ: ਡੌਕਰਫਾਈਲਾਂ ਤੋਂ ਪਰੇ ਬਿਲਡਿੰਗ

ਸ਼ਾਇਦ ਬਿਲਡਕਿੱਟ ਦੀ ਸਭ ਤੋਂ ਘੱਟ ਜਾਣੀ ਜਾਣ ਵਾਲੀ ਸਮਰੱਥਾ ਇਹ ਹੈ ਕਿ ਡੌਕਰਫਾਈਲ ਸਿਰਫ਼ ਇੱਕ ਸੰਭਾਵਿਤ ਇਨਪੁਟ ਫਾਰਮੈਟ ਹਨ — ਸਿਰਫ਼ ਇੱਕ ਨਹੀਂ। ਬਿਲਡਕਿਟ ਵਿੱਚ ਇੱਕ ਪਲੱਗੇਬਲ ਫਰੰਟਐਂਡ ਆਰਕੀਟੈਕਚਰ ਹੈ ਜੋ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਸਟਮ ਬਿਲਡ ਪਰਿਭਾਸ਼ਾ ਭਾਸ਼ਾਵਾਂ ਅਤੇ ਫਾਰਮੈਟਾਂ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਫਰੰਟਐਂਡ ਤੁਹਾਡੀ ਬਿਲਡ ਫਾਈਲ ਦੇ ਸਿਖਰ 'ਤੇ # ਸਿੰਟੈਕਸ= ਨਿਰਦੇਸ਼ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ ਬਿਲਡਕਿੱਟ ਨੂੰ ਇੱਕ ਖਾਸ ਫਰੰਟਐਂਡ ਚਿੱਤਰ ਨੂੰ ਖਿੱਚਣ ਅਤੇ ਬਾਕੀ ਫਾਈਲ ਨੂੰ ਪਾਰਸ ਕਰਨ ਅਤੇ ਚਲਾਉਣ ਲਈ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ।

ਇਸ ਆਰਕੀਟੈਕਚਰ ਨੇ ਕਈ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਸਮਰੱਥ ਬਣਾਇਆ ਹੈ। ਬਿਲਡਪੈਕਸ ਏਕੀਕਰਣ ਬਿਲਡਕਿੱਟ ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਡੌਕਰਫਾਈਲ ਦੇ ਐਪਲੀਕੇਸ਼ਨ ਸੋਰਸ ਕੋਡ ਤੋਂ ਕੰਟੇਨਰ ਚਿੱਤਰ ਬਣਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ — ਇਹ ਭਾਸ਼ਾ ਦਾ ਪਤਾ ਲਗਾਉਂਦਾ ਹੈ, ਉਚਿਤ ਅਧਾਰ ਚਿੱਤਰਾਂ ਦੀ ਚੋਣ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਉਤਪਾਦਨ-ਤਿਆਰ ਕੰਟੇਨਰ ਨੂੰ ਆਪਣੇ ਆਪ ਇਕੱਠਾ ਕਰਦਾ ਹੈ। HPC ਅਤੇ ਵਿਗਿਆਨਕ ਕੰਪਿਊਟਿੰਗ ਕਮਿਊਨਿਟੀਆਂ ਨੇ ਡੋਮੇਨ-ਵਿਸ਼ੇਸ਼ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਬਿਲਡਾਂ ਦਾ ਵਰਣਨ ਕਰਨ ਲਈ ਕਸਟਮ ਫਰੰਟਐਂਡ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ ਜੋ ਬਿਲਡਕਿੱਟ ਦੀ ਅੰਦਰੂਨੀ LLB (ਲੋਅ-ਲੈਵਲ ਬਿਲਡ) ਨੁਮਾਇੰਦਗੀ ਲਈ ਕੰਪਾਇਲ ਕਰਦੇ ਹਨ। docker/dockerfile:labs ਸਥਾਈ ਡੌਕਰਫਾਈਲ ਸੰਟੈਕਸ ਵਿੱਚ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ heredoc ਸਮਰਥਨ, --network ਨਿਯੰਤਰਣ ਪ੍ਰਤੀ ਨਿਰਦੇਸ਼, ਅਤੇ ਵਿਸਤ੍ਰਿਤ ਕੈਸ਼ ਸੰਕੇਤ ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਨਾਲ ਸਿੰਟੈਕਸ ਫਰੰਟਐਂਡ ਪ੍ਰਯੋਗ ਕਰਦਾ ਹੈ।

ਤੁਹਾਡੇ ਆਪਣੇ ਫਰੰਟਐਂਡ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦੀ ਯੋਗਤਾ ਦਾ ਮਤਲਬ ਇਹ ਵੀ ਹੈ ਕਿ ਅਸਾਧਾਰਨ ਬਿਲਡ ਲੋੜਾਂ ਵਾਲੇ ਸੰਗਠਨਾਂ ਨੂੰ "ਡੌਕਰਫਾਈਲ ਸੰਟੈਕਸ ਵਿੱਚ ਹਰ ਚੀਜ਼ ਨੂੰ ਸ਼ੋਹੋਰਨ" ਅਤੇ "ਕੰਟੇਨਰਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡ ਦਿਓ" ਵਿਚਕਾਰ ਚੋਣ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇੱਕ ਟੀਮ ਬਿਲਡਿੰਗ FPGA ਫਰਮਵੇਅਰ, ਏਮਬੇਡਡ ਸਿਸਟਮ ਚਿੱਤਰ, ਜਾਂ ਵਿਸ਼ੇਸ਼ ML ਮਾਡਲ ਕੰਟੇਨਰ ਉਹਨਾਂ ਦੇ ਬਿਲਡ ਦਾ ਵਰਣਨ ਉਹਨਾਂ ਸ਼ਬਦਾਂ ਵਿੱਚ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਉਹਨਾਂ ਦੇ ਡੋਮੇਨ ਲਈ ਅਰਥ ਬਣਾਉਂਦੇ ਹਨ ਜਦੋਂ ਕਿ ਅਜੇ ਵੀ ਮਿਆਰੀ OCI-ਅਨੁਕੂਲ ਕੰਟੇਨਰ ਚਿੱਤਰਾਂ ਦਾ ਉਤਪਾਦਨ ਕਰਦੇ ਹਨ ਜੋ ਕਿ ਕਿਤੇ ਵੀ ਕੰਟੇਨਰ ਚੱਲਦੇ ਹਨ। ਇਹ ਵਿਸਤਾਰਸ਼ੀਲਤਾ ਬਿਲਡ ਸਿਸਟਮਾਂ ਨਾਲੋਂ ਇੱਕ ਅਸਲ ਆਰਕੀਟੈਕਚਰਲ ਫਾਇਦਾ ਹੈ ਜੋ ਉਹਨਾਂ ਦੇ ਇਨਪੁਟ ਫਾਰਮੈਟ ਨੂੰ ਸਥਿਰ ਮੰਨਦੇ ਹਨ।

ਪ੍ਰੋਵੇਨੈਂਸ ਅਤੇ SBOM: ਸੋਲਰ-ਵਿੰਡਸ ਵਰਲਡ ਲਈ ਬਿਲਡਿੰਗ

ਸਾਫਟਵੇਅਰ ਸਪਲਾਈ ਚੇਨ ਸੁਰੱਖਿਆ 2020 ਵਿੱਚ SolarWinds ਦੀ ਉਲੰਘਣਾ ਅਤੇ 2021 ਵਿੱਚ Log4Shell ਦੀ ਕਮਜ਼ੋਰੀ ਤੋਂ ਬਾਅਦ ਸਿਧਾਂਤਕ ਚਿੰਤਾ ਤੋਂ ਬੋਰਡ-ਪੱਧਰ ਦੀ ਤਰਜੀਹ ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਗਈ। ਸਾਈਬਰ ਸੁਰੱਖਿਆ 'ਤੇ ਅਮਰੀਕੀ ਸਰਕਾਰ ਦੇ ਕਾਰਜਕਾਰੀ ਆਰਡਰ 14028, ਮਈ 2021 ਵਿੱਚ ਸਾੱਫਟਵੇਅਰਾਂ ਦੇ ਕੰਟਰੈਕਟ ਬਿਲਾਂ ਲਈ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਜਾਰੀ ਕੀਤਾ ਗਿਆ। BuildKit ਦੇ ਮੂਲ ਪ੍ਰਮਾਣੀਕਰਨ ਅਤੇ SBOM ਜਨਰੇਸ਼ਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਇਸ ਰੈਗੂਲੇਟਰੀ ਅਤੇ ਸੁਰੱਖਿਆ ਲੈਂਡਸਕੇਪ ਦਾ ਸਿੱਧਾ ਜਵਾਬ ਹਨ।

--provenance=true ਅਤੇ --sbom=true ਫਲੈਗਾਂ ਦੇ ਨਾਲ, BuildKit ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਤੌਰ 'ਤੇ ਹਸਤਾਖਰਿਤ ਤਸਦੀਕ ਬਣਾਉਂਦੀ ਹੈ ਜੋ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਕੰਟੇਨਰ ਚਿੱਤਰ ਵਿੱਚ ਕੀ ਗਿਆ ਸੀ — ਕਿਹੜੀਆਂ ਬੇਸ ਚਿੱਤਰਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ, ਕਿਹੜੀਆਂ ਡੌਕਰਫਾਈਲ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਸੀ, ਕਿਹੜੀਆਂ ਸਰੋਤ ਫਾਈਲਾਂ ਮੌਜੂਦ ਸਨ, ਅਤੇ ਕਿਹੜੀਆਂ ਫੈਚਨਲ ਫਾਈਲਾਂ ਮੌਜੂਦ ਸਨ। ਇਹ ਤਸਦੀਕ SLSA (ਸਾਫਟਵੇਅਰ ਆਰਟੀਫੈਕਟਸ ਲਈ ਸਪਲਾਈ-ਚੇਨ ਲੈਵਲ) ਫਰੇਮਵਰਕ ਅਤੇ ਇਨ-ਟੋਟੋ ਤਸਦੀਕ ਫਾਰਮੈਟ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ, ਇਹਨਾਂ ਨੂੰ ਸਿਗਸਟੋਰ ਦੇ ਕੋਸਾਈਨ ਅਤੇ ਓਪੀਏ (ਓਪਨ ਪਾਲਿਸੀ ਏਜੰਟ) ਵਰਗੇ ਪਾਲਿਸੀ ਇੰਜਣਾਂ ਦੁਆਰਾ ਮਸ਼ੀਨ ਦੁਆਰਾ ਪ੍ਰਮਾਣਿਤ ਬਣਾਉਂਦੇ ਹਨ।

ਵਿਹਾਰਕ ਵਰਕਫਲੋ ਇਸ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ:

1. ਵਿਕਾਸਕਾਰ ਕੋਡ ਨੂੰ ਧੱਕਦਾ ਹੈ; CI ਪਾਈਪਲਾਈਨ ਪ੍ਰੋਵੇਨੈਂਸ ਸਮਰਥਿਤ ਇੱਕ ਬਿਲਡਕਿੱਟ ਬਿਲਡ ਨੂੰ ਚਾਲੂ ਕਰਦੀ ਹੈ।
2. ਬਿਲਡਕਿੱਟ ਸਾਰੇ ਭਾਗਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਸੰਸਕਰਣਾਂ ਨੂੰ ਸੂਚੀਬੱਧ ਕਰਨ ਲਈ ਇੱਕ ਹਸਤਾਖਰਿਤ SBOM ਬਣਾਉਂਦਾ ਹੈ।
3. ਐਸਬੀਓਐਮ ਨੂੰ ਚਿੱਤਰ ਮੈਨੀਫੈਸਟ ਦੇ ਨਾਲ ਕੰਟੇਨਰ ਰਜਿਸਟਰੀ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
4. ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਵਿੱਚ ਦਾਖਲਾ ਕੰਟਰੋਲਰ ਤੈਨਾਤੀ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਮੂਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ।
5. ਨਵੇਂ CVE ਦਾ ਖੁਲਾਸਾ ਹੋਣ 'ਤੇ ਕਮਜ਼ੋਰੀ ਸਕੈਨਰ ਪ੍ਰਭਾਵਿਤ ਚਿੱਤਰਾਂ ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ SBOM ਤੋਂ ਪੁੱਛਗਿੱਛ ਕਰਦੇ ਹਨ।

ਇਸ ਪੂਰੀ ਪਾਈਪਲਾਈਨ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਾਲੀਆਂ ਟੀਮਾਂ ਦਿਨਾਂ ਦੀ ਬਜਾਏ ਘੰਟਿਆਂ ਵਿੱਚ ਕਮਜ਼ੋਰੀ ਦੇ ਖੁਲਾਸੇ ਦਾ ਜਵਾਬ ਦੇ ਸਕਦੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਉਹਨਾਂ ਕੋਲ ਹਰੇਕ ਚੱਲ ਰਹੇ ਕੰਟੇਨਰ ਵਿੱਚ ਹਰੇਕ ਕੰਪੋਨੈਂਟ ਦਾ ਸਟੀਕ, ਮਸ਼ੀਨ ਦੁਆਰਾ ਪੜ੍ਹਨਯੋਗ ਨਕਸ਼ਾ ਹੁੰਦਾ ਹੈ। Mewayz ਵਰਗੇ ਕਾਰੋਬਾਰਾਂ ਲਈ ਜੋ ਗਾਹਕਾਂ ਦੇ ਸੰਚਾਲਨ ਕਾਰਜ-ਪ੍ਰਵਾਹ ਵਿੱਚ ਡੂੰਘਾਈ ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਹੁੰਦੇ ਹਨ — ਪੈਰੋਲ ਚਲਾਉਣਾ, ਫਲੀਟ ਡੇਟਾ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ, ਇਨਵੌਇਸਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ — ਇੱਕ ਸਖ਼ਤ, ਆਡਿਟ ਕਰਨ ਯੋਗ ਸਪਲਾਈ ਚੇਨ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਸਿਰਫ ਇੱਕ ਚੰਗੀ-ਹੋਣ ਵਾਲੀ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਿਕਰੀ ਗੱਲਬਾਤ ਲਈ ਇੱਕ ਪੂਰਵ ਸ਼ਰਤ ਹੈ।

ਸ਼ੁਰੂ ਕਰਨਾ: ਡਿਫੌਲਟ ਬਿਲਡਸ ਤੋਂ ਐਡਵਾਂਸਡ ਪਾਈਪਲਾਈਨਾਂ ਤੱਕ

ਬਿਲਡਕਿੱਟ ਤੁਹਾਡੇ ਡੌਕਰ ਵਾਤਾਵਰਣ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਚੱਲ ਰਹੀ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਤਾਜ਼ਾ ਸੰਸਕਰਣ ਵਰਤ ਰਹੇ ਹੋ — ਡੌਕਰ 23.0 ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਇਸਨੂੰ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਸਮਰੱਥ ਕਰੋ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਲਈ ਪਹਿਲਾ ਵਿਹਾਰਕ ਕਦਮ ਡੌਕਰ ਬਿਲਡਐਕਸ ਪਲੱਗਇਨ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਣਾ ਹੈ, ਜੋ ਬਿਲਡਕਿੱਟ ਦੀ ਪੂਰੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ docker buildx ਸਬ-ਕਮਾਂਡ ਰਾਹੀਂ ਸੈੱਟ ਕਰਦਾ ਹੈ। docker buildx create --use ਨੂੰ ਚਲਾਉਣਾ ਇੱਕ ਬਿਲਡਕਿੱਟ ਬਿਲਡਰ ਇੰਸਟੈਂਸ ਨੂੰ ਡਿਫਾਲਟ ਡਰਾਈਵਰ ਨਾਲੋਂ ਵੱਧ ਸਮਰੱਥਾ ਨਾਲ ਸੈਟ ਅਪ ਕਰਦਾ ਹੈ। ਉੱਥੋਂ, ਉੱਨਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਵਧਾਉਣਾ ਇੱਕ ਵਾਰ ਵਿੱਚ ਸਭ ਕੁਝ ਅਪਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਬਜਾਏ ਅਰਥ ਰੱਖਦਾ ਹੈ।

ਇਸ ਸਮੇਂ ਮੂਲ ਡੌਕਰ ਬਿਲਡ ਇਨਵੋਕੇਸ਼ਨ ਕਰ ਰਹੀ ਟੀਮ ਲਈ ਇੱਕ ਵਾਜਬ ਅਪਣਾਉਣ ਦਾ ਮਾਰਗ ਪਹਿਲਾਂ CI ਵਿੱਚ ਕੈਸ਼ ਨਿਰਯਾਤ ਜੋੜਨ ਵਰਗਾ ਲੱਗਦਾ ਹੈ — ਇਹ ਘੱਟੋ-ਘੱਟ ਕੌਂਫਿਗਰੇਸ਼ਨ ਤਬਦੀਲੀ ਦੇ ਨਾਲ ਤੁਰੰਤ, ਮਾਪਣਯੋਗ ਗਤੀ ਸੁਧਾਰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਮਲਟੀ-ਪਲੇਟਫਾਰਮ ਬਿਲਡ ਕੀਮਤੀ ਬਣ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਟੀਮ ARM ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ। ਗੁਪਤ ਮਾਊਂਟਿੰਗ ਕਿਸੇ ਵੀ ਸਮੇਂ ਨਿੱਜੀ ਪੈਕੇਜ ਰਜਿਸਟਰੀਆਂ ਜਾਂ SSH ਕੁੰਜੀਆਂ ਬਿਲਡ ਸੰਦਰਭ ਵਿੱਚ ਦਿਖਾਈ ਦੇਣ ਦੇ ਯੋਗ ਹੈ। ਜਦੋਂ ਪਾਲਣਾ ਲੋੜਾਂ ਜਾਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਗਾਹਕਾਂ ਦੀਆਂ ਮੰਗਾਂ ਸਪਲਾਈ ਚੇਨ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਜ਼ਰੂਰੀ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਤਾਂ ਪ੍ਰੋਵੇਨੈਂਸ ਤਸਦੀਕ ਨੂੰ ਯੋਗ ਬਣਾਉਣਾ ਸਮਝਦਾਰ ਹੁੰਦਾ ਹੈ।

ਬਿਲਡਕਿੱਟ ਦਾ ਡੂੰਘਾ ਸਬਕ ਜਾਣਬੁੱਝ ਕੇ ਬਣਾਉਣ ਬਾਰੇ ਹੈ। ਭਾਵੇਂ ਤੁਸੀਂ ਮਾਈਕ੍ਰੋਸਰਵਿਸ, ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਇਨਫਰੈਂਸ ਐਂਡਪੁਆਇੰਟ, ਜਾਂ ਮੇਵੇਜ਼ ਦੇ 207 ਬਿਜ਼ਨਸ ਮੋਡੀਊਲ ਦੇ ਸੂਟ ਵਰਗਾ ਇੱਕ ਗੁੰਝਲਦਾਰ ਪਲੇਟਫਾਰਮ ਲਈ ਇੱਕ ਕੰਟੇਨਰ ਸ਼ਿਪਿੰਗ ਕਰ ਰਹੇ ਹੋ, ਬਿਲਡ ਪ੍ਰਕਿਰਿਆ ਇੱਕ ਰਸਮੀਤਾ ਨਹੀਂ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਤੈਨਾਤੀ ਦੇ ਰਸਤੇ ਵਿੱਚ ਪੂਰਾ ਕਰਦੇ ਹੋ - ਇਹ ਇੱਕ ਇੰਜਨੀਅਰਿੰਗ ਆਰਟੀਫੈਕਟ ਹੈ ਜੋ ਗੁਣਵੱਤਾ, ਸੁਰੱਖਿਆ ਸਥਿਤੀ, ਅਤੇ ਹਰ ਚੀਜ਼ ਦੀ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਬਿਲਡਕਿੱਟ ਤੁਹਾਨੂੰ ਉਸ ਆਰਟੀਫੈਕਟ ਨੂੰ ਸ਼ਾਨਦਾਰ ਬਣਾਉਣ ਲਈ ਟੂਲ ਦਿੰਦੀ ਹੈ। ਸਵਾਲ ਸਿਰਫ਼ ਇਹ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ ਇਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਸਮਾਂ ਕੱਢਦੇ ਹੋ।

ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ

ਬਿਲਡਕਿਟ ਕੀ ਹੈ ਅਤੇ ਇਹ ਕਲਾਸਿਕ ਡੌਕਰ ਬਿਲਡ ਸਿਸਟਮ ਤੋਂ ਕਿਵੇਂ ਵੱਖਰਾ ਹੈ?

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

ਕੀ ਮੈਨੂੰ ਡੌਕਰ ਨਾਲ ਬਿਲਡਕਿੱਟ ਦੀ ਵਰਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਕੁਝ ਵਾਧੂ ਸਥਾਪਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ?

ਕੋਈ ਵਾਧੂ ਇੰਸਟਾਲੇਸ਼ਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਡੌਕਰ 23.0 ਜਾਂ ਇਸ ਤੋਂ ਬਾਅਦ ਦਾ ਵਰਜਨ ਚਲਾ ਰਹੇ ਹੋ — ਬਿਲਡਕਿੱਟ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਮਰੱਥ ਹੈ। ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ 'ਤੇ, ਤੁਸੀਂ ਆਪਣੀਆਂ ਬਿਲਡ ਕਮਾਂਡਾਂ ਨੂੰ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ DOCKER_BUILDKIT=1 ਸੈੱਟ ਕਰਕੇ ਇਸਨੂੰ ਸਰਗਰਮ ਕਰ ਸਕਦੇ ਹੋ। ਰਿਮੋਟ ਬਿਲਡ ਕੈਚ ਜਾਂ ਮਲਟੀ-ਪਲੇਟਫਾਰਮ ਬਿਲਡ ਵਰਗੇ ਉੱਨਤ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਲਈ, ਤੁਸੀਂ docker buildx create ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਸਮਰਪਿਤ Buildx ਬਿਲਡਰ ਉਦਾਹਰਨ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨਾ ਚਾਹ ਸਕਦੇ ਹੋ।

ਕੀ ਬਿਲਡਕਿੱਟ ਦੀ ਵਰਤੋਂ ਮਿਆਰੀ ਕੰਟੇਨਰ ਚਿੱਤਰਾਂ ਤੋਂ ਪਰੇ ਕਲਾਤਮਕ ਚੀਜ਼ਾਂ ਬਣਾਉਣ ਲਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ?

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

Mewayz ਵਰਗੇ ਟੂਲਸ ਦੇ ਨਾਲ ਇੱਕ ਵਿਸ਼ਾਲ DevOps ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਬਿਲਡਕਿੱਟ ਕਿਵੇਂ ਫਿੱਟ ਹੁੰਦੀ ਹੈ?

ਬਿਲਡਕਿੱਟ ਘੱਟ-ਪੱਧਰੀ ਬਿਲਡ ਲੇਅਰ ਨੂੰ ਹੈਂਡਲ ਕਰਦੀ ਹੈ, ਪਰ ਆਧੁਨਿਕ ਵਿਕਾਸ ਟੀਮਾਂ ਨੂੰ ਕਾਰੋਬਾਰੀ ਵਰਕਫਲੋ, ਕਲਾਇੰਟ ਡਿਲੀਵਰੀ, ਅਤੇ ਸੰਚਾਲਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਵੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ ਕਿ Mewayz — ਇੱਕ 207-ਮੋਡਿਊਲ ਕਾਰੋਬਾਰੀ OS ਜੋ $19/mo ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ — ਸਾਫਟਵੇਅਰ ਕਾਰੋਬਾਰਾਂ ਦੇ ਸੰਚਾਲਨ ਪੱਖ ਨੂੰ ਕਵਰ ਕਰਕੇ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਟੂਲਿੰਗ ਨੂੰ ਪੂਰਕ ਕਰਦੇ ਹਨ। ਮੇਵੇਜ਼ ਵਰਗੇ ਆਲ-ਇਨ-ਵਨ ਪਲੇਟਫਾਰਮ ਦੇ ਨਾਲ ਬਿਲਡਕਿੱਟ ਦੁਆਰਾ ਸੰਚਾਲਿਤ ਕੁਸ਼ਲ ਬਿਲਡ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਜੋੜਨਾ ਟੀਮਾਂ ਨੂੰ ਕੋਡ ਆਰਟੀਫੈਕਟ ਤੋਂ ਗਾਹਕ ਡਿਲੀਵਰੀ ਤੱਕ ਪੂਰਾ ਸਟੈਕ ਦਿੰਦਾ ਹੈ।