Ciao, sviluppatori! In questo articolo parler\u00f2 di CI\/CD \u2013 un concetto.<\/p>\n\n\n\n
pytest<\/code> e flake8<\/code>)<\/a><\/li>- \ud83c\udf10 CI\/CD per Node.js (con
npm test<\/code> e eslint<\/code>)<\/a><\/li>- \ud83d\udc33 CI\/CD per Docker (build e push su Docker Hub)<\/a><\/li><\/ul><\/li>
- \ud83d\ude9a Distribuzione su piattaforme popolari<\/a>
- \ud83d\udfe3 Distribuzione su Heroku<\/a><\/li><\/ul><\/li>
- \ud83d\udfe8 Distribuzione su AWS (ad esempio, file statici su S3)<\/a><\/li>
- \ud83d\udd35 Distribuzione su Google Cloud Platform (GCP App Engine)<\/a>
- \ud83d\udfea Distribuzione su Render.com<\/a><\/li><\/ul><\/li>
- \ud83c\udf1f CI\/CD avanzato: Build Docker \u2192 Push su GHCR \u2192 Staging\/Production su GCP Cloud Run<\/a><\/li>
- 1. Build e pubblicazione dell’immagine Docker su GHCR<\/a><\/li>
- 2. Distribuzione automatica su Staging (GCP Cloud Run)<\/a><\/li>
- 3. Distribuzione in produzione con conferma manuale (GCP Cloud Run)<\/a><\/li>
- Punti importanti di questa pipeline avanzata:<\/a><\/li>
- \ud83d\udd10 Sicurezza \u2013 \u00e8 importante!<\/a><\/li>
- Cos’\u00e8 una pipeline CI\/CD nel contesto della programmazione?<\/a><\/li>
- \ud83d\udd04 Di cosa \u00e8 composta di solito una pipeline CI\/CD?<\/a><\/li>
- \ud83d\udee0 Strumenti popolari per CI\/CD:<\/a><\/li>
- \ud83e\udde0 Perch\u00e9 abbiamo bisogno di CI\/CD?<\/a><\/li>
- \ud83d\udce6 Esempi semplici di CI\/CD con GitHub Actions<\/a>
- \ud83d\udc0d CI\/CD per Python (con
pytest<\/code> e flake8<\/code>)<\/a><\/li>- \ud83c\udf10 CI\/CD per Node.js (con
npm test<\/code> e eslint<\/code>)<\/a><\/li>- \ud83d\udc33 CI\/CD per Docker (build e push su Docker Hub)<\/a><\/li><\/ul><\/li>
- \ud83d\ude9a Distribuzione su piattaforme popolari<\/a>
- \ud83d\udfe3 Distribuzione su Heroku<\/a><\/li><\/ul><\/li>
- \ud83d\udfe8 Distribuzione su AWS (ad esempio, file statici su S3)<\/a><\/li>
- \ud83d\udd35 Distribuzione su Google Cloud Platform (GCP App Engine)<\/a>
- \ud83d\udfea Distribuzione su Render.com<\/a><\/li><\/ul><\/li>
- \ud83c\udf1f CI\/CD avanzato: Build Docker \u2192 Push su GHCR \u2192 Staging\/Production su GCP Cloud Run<\/a><\/li>
- 1. Build e pubblicazione dell’immagine Docker su GHCR<\/a><\/li>
- 2. Distribuzione automatica su Staging (GCP Cloud Run)<\/a><\/li>
- 3. Distribuzione in produzione con conferma manuale (GCP Cloud Run)<\/a><\/li>
- Punti importanti di questa pipeline avanzata:<\/a><\/li>
- \ud83d\udd10 Sicurezza \u2013 \u00e8 importante!<\/a><\/li><\/ul><\/li><\/ol><\/div>
Cos’\u00e8 una pipeline CI\/CD nel contesto della programmazione?<\/h3>\n\n\n\n
Una pipeline CI\/CD (Continuous Integration \/ Continuous Delivery o Continuous Deployment)<\/strong> \u00e8 un processo automatizzato che consente agli sviluppatori di consegnare rapidamente e in modo affidabile le modifiche al codice in un ambiente di produzione.<\/p>\n\n\n\nAnalizziamo i concetti chiave:<\/p>\n\n\n\n
\ud83d\udd27 CI \u2014 Continuous Integration (Integrazione Continua)<\/strong>
Questa \u00e8 una pratica in cui gli sviluppatori integrano frequentemente le modifiche in una codebase condivisa. Ogni modifica di questo tipo viene automaticamente: * Costruita<\/strong> (build) * Testata<\/strong> (test unitari, test di integrazione) * Verificata per la conformit\u00e0 agli standard<\/strong> (linting, analisi statica)<\/p>\n\n\n\n\ud83d\udc49 **Obiettivo della CI:** Identificare gli errori il prima possibile, prima che rompano qualcosa di importante o finiscano in una release.<\/p>\n\n\n\n
\ud83d\ude80 **CD \u2014 Continuous Delivery (Consegna Continua) o Continuous Deployment (Distribuzione Continua)**
Qui ci sono due opzioni:<\/p>\n\n\n\n
\u2705 **Continuous Delivery (Consegna Continua)**
Dopo il successo della fase CI, le modifiche vengono automaticamente: * Sottoposte a test aggiuntivi (ad esempio, test E2E \u2013 end-to-end) * Distribuite su un server di staging (test)<\/p>\n\n\n\n
\ud83d\udc49 **Ma la distribuzione in produzione richiede ancora una conferma manuale.** Questo d\u00e0 al team il controllo su *quando* esattamente gli utenti vedranno le modifiche.<\/p>\n\n\n\n
\ud83e\udd16 **Continuous Deployment (Distribuzione Continua)**
Questo \u00e8 il passo successivo dopo la Continuous Delivery. Qui, la distribuzione in produzione avviene **completamente automaticamente**, se tutte le fasi precedenti della pipeline (build, tutti i test) sono state completate con successo. Questo \u00e8 il livello pi\u00f9 avanzato di automazione.<\/p>\n\n\n\n
\ud83d\udd04 Di cosa \u00e8 composta di solito una pipeline CI\/CD?<\/h3>\n\n\n\n
Una pipeline tipica include le seguenti fasi:<\/p>\n\n\n\n
\n- Checkout<\/strong> \u2014 Clonazione dell’ultima versione del codice dal repository.<\/li>\n\n\n\n
- Build<\/strong> \u2014 Costruzione del progetto (compilazione, assemblaggio di artefatti, immagini Docker).<\/li>\n\n\n\n
- Test<\/strong> \u2014 Esecuzione di vari tipi di test (unitari, di integrazione, E2E).<\/li>\n\n\n\n
- Lint\/Code Quality<\/strong> \u2014 Controllo del codice per la conformit\u00e0 allo stile e potenziali errori utilizzando analizzatori statici.<\/li>\n\n\n\n
- Deploy<\/strong> \u2014 Distribuzione dell’applicazione (su un server di staging o di produzione).<\/li>\n\n\n\n
- Notify<\/strong> \u2014 Invio di notifiche sullo stato della pipeline al team (ad esempio, in Slack, Email).<\/li>\n<\/ol>\n\n\n\n
\ud83d\udee0 Strumenti popolari per CI\/CD:<\/h3>\n\n\n\n\n- GitHub Actions<\/strong> (il nostro focus oggi!)<\/li>\n\n\n\n
- GitLab CI\/CD<\/li>\n\n\n\n
- Jenkins<\/li>\n\n\n\n
- CircleCI<\/li>\n\n\n\n
- Bitbucket Pipelines<\/li>\n\n\n\n
- Azure DevOps<\/li>\n\n\n\n
- TeamCity<\/li>\n<\/ul>\n\n\n\n
\ud83e\udde0 Perch\u00e9 abbiamo bisogno di CI\/CD?<\/h3>\n\n\n\n\n- Riduce l’errore umano:<\/strong> L’automazione elimina gli errori associati alle operazioni manuali.<\/li>\n\n\n\n
- Rilevamento rapido dei bug:<\/strong> Gli errori vengono trovati prima, rendendoli pi\u00f9 facili e meno costosi da correggere.<\/li>\n\n\n\n
- Automazione delle attivit\u00e0 di routine:<\/strong> Gli sviluppatori dedicano meno tempo alla costruzione e alla distribuzione e pi\u00f9 tempo alla codifica.<\/li>\n\n\n\n
- Miglioramento della qualit\u00e0 del codice:<\/strong> Controlli e test continui aumentano il livello di qualit\u00e0 complessivo.<\/li>\n\n\n\n
- Consegna rapida delle funzionalit\u00e0 agli utenti:<\/strong> Le nuove funzionalit\u00e0 raggiungono l’utente finale pi\u00f9 rapidamente e pi\u00f9 frequentemente.<\/li>\n<\/ul>\n\n\n\n
\ud83d\udce6 Esempi semplici di CI\/CD con GitHub Actions<\/h3>\n\n\n\n
Diamo un’occhiata alle pipeline di base per le tecnologie pi\u00f9 diffuse. Tutti gli esempi utilizzano GitHub Actions e vengono salvati nella directory .github\/workflows\/<\/code> del tuo progetto.<\/p>\n\n\n\n\ud83d\udc0d CI\/CD per Python (con pytest<\/code> e flake8<\/code>)<\/h4>\n\n\n\n# .github\/workflows\/python-ci.yml\nname: Python CI\n\non: [push, pull_request]\n\njobs:\n build:\n runs-on: ubuntu-latest\n\n steps:\n - uses: actions\/checkout@v3\n\n - name: Set up Python\n uses: actions\/setup-python@v4\n with:\n python-version: '3.11' # Specifica la tua versione\n\n - name: Install dependencies\n run: |\n python -m pip install --upgrade pip\n pip install -r requirements.txt # Assicurati di avere requirements.txt\n pip install flake8 pytest\n\n - name: Lint with flake8\n run: |\n # Controlla il codice nelle cartelle src e tests (adatta al tuo progetto)\n flake8 src tests\n\n - name: Run tests\n run: |\n pytest\n<\/code><\/pre>\n\n\n\n\ud83c\udf10 CI\/CD per Node.js (con npm test<\/code> e eslint<\/code>)<\/h4>\n\n\n\n# .github\/workflows\/node-ci.yml\nname: Node.js CI\n\non: [push, pull_request]\n\njobs:\n build:\n runs-on: ubuntu-latest\n\n strategy:\n matrix:\n node-version: [18.x] # Specifica la tua versione di Node.js\n\n steps:\n - uses: actions\/checkout@v3\n\n - name: Use Node.js ${{ matrix.node-version }}\n uses: actions\/setup-node@v4\n with:\n node-version: ${{ matrix.node-version }}\n\n - name: Install dependencies\n run: npm install # o npm ci per un'installazione pi\u00f9 prevedibile\n\n - name: Lint with ESLint\n run: npx eslint . # Assicurati che ESLint sia configurato nel progetto\n\n - name: Run tests\n run: npm test\n<\/code><\/pre>\n\n\n\n\ud83d\udc33 CI\/CD per Docker (build e push su Docker Hub)<\/h4>\n\n\n\n
Per questo esempio, avrai bisogno dei segreti DOCKER_USERNAME<\/code> e DOCKER_PASSWORD<\/code> (o un token) nelle impostazioni del tuo repository GitHub (Settings -> Secrets and variables -> Actions<\/code>).<\/p>\n\n\n\n# .github\/workflows\/docker-ci.yml\nname: Docker CI\/CD\n\non:\n push:\n branches: [ main ] # Esegui solo per il branch main\n\njobs:\n docker:\n runs-on: ubuntu-latest\n\n steps:\n - uses: actions\/checkout@v3\n\n - name: Log in to Docker Hub\n run: echo "${{ secrets.DOCKER_PASSWORD }}" | docker login -u "${{ secrets.DOCKER_USERNAME }}" --password-stdin\n\n - name: Build Docker image\n # Sostituisci myapp con il nome della tua applicazione\n run: docker build -t ${{ secrets.DOCKER_USERNAME }}\/myapp:latest .\n\n - name: Push Docker image\n run: docker push ${{ secrets.DOCKER_USERNAME }}\/myapp:latest\n<\/code><\/pre>\n\n\n\n\ud83d\ude9a Distribuzione su piattaforme popolari<\/h3>\n\n\n\n
Ora che abbiamo artefatti costruiti e testati (ad esempio, un’immagine Docker), vediamo come possono essere distribuiti.<\/p>\n\n\n\n
\ud83d\udfe3 Distribuzione su Heroku<\/h4>\n\n\n\n
\ud83d\udd10 Segreti GitHub:<\/strong> HEROKU_API_KEY<\/code>, HEROKU_APP_NAME<\/code>.<\/p>\n\n\n\n# .github\/workflows\/deploy-heroku.yml\nname: Deploy to Heroku\n\non:\n push:\n branches: [main]\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v3\n - name: Install Heroku CLI\n run: curl https:\/\/cli-assets.heroku.com\/install.sh | sh\n - name: Login to Heroku\n env:\n HEROKU_API_KEY: ${{ secrets.HEROKU_API_KEY }}\n run: heroku auth:token\n - name: Deploy to Heroku\n env:\n HEROKU_API_KEY: ${{ secrets.HEROKU_API_KEY }}\n run: |\n heroku git:remote -a ${{ secrets.HEROKU_APP_NAME }}\n git push heroku main -f # Fai attenzione con -f (force push)\n<\/code><\/pre>\n\n\n\nSe stai distribuendo un’immagine Docker su Heroku:<\/p>\n\n\n\n
# ... (passaggi di build e login a Docker Hub\/GHCR dagli esempi precedenti) ...\n# deploy:\n# name: Deploy to Heroku\n# needs: build # Dipende dal job di build dell'immagine\n# runs-on: ubuntu-latest\n# steps:\n# # ...\n# - name: Login to Heroku container registry\n# run: echo "${{ secrets.HEROKU_API_KEY }}" | docker login --username=_ --password-stdin registry.heroku.com\n# - name: Tag image for Heroku\n# # Supponendo che l'immagine sia costruita come ghcr.io\/username\/repo\/myapp:latest\n# run: docker tag ghcr.io\/${{ github.repository_owner }}\/${{ github.event.repository.name }}\/myapp:latest registry.heroku.com\/${{ secrets.HEROKU_APP_NAME }}\/web\n# - name: Push image to Heroku\n# run: docker push registry.heroku.com\/${{ secrets.HEROKU_APP_NAME }}\/web\n# - name: Release Heroku App\n# env:\n# HEROKU_API_KEY: ${{ secrets.HEROKU_API_KEY }}\n# run: heroku container:release web --app ${{ secrets.HEROKU_APP_NAME }}\n<\/code><\/pre>\n\n\n\n\ud83d\udfe8 Distribuzione su AWS (ad esempio, file statici su S3)<\/h3>\n\n\n\n
\ud83d\udd10 Segreti GitHub:<\/strong> AWS_ACCESS_KEY_ID<\/code>, AWS_SECRET_ACCESS_KEY<\/code>, AWS_REGION<\/code>, S3_BUCKET_NAME<\/code>.<\/p>\n\n\n\n# .github\/workflows\/deploy-aws-s3.yml\nname: Deploy Static Site to AWS S3\n\non:\n push:\n branches: [main]\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v3\n - name: Configure AWS credentials\n uses: aws-actions\/configure-aws-credentials@v4\n with:\n aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}\n aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}\n aws-region: ${{ secrets.AWS_REGION }}\n - name: Sync files to S3\n # Sostituisci .\/public con il percorso dei tuoi file statici\n run: aws s3 sync .\/public s3:\/\/${{ secrets.S3_BUCKET_NAME }} --delete\n<\/code><\/pre>\n\n\n\nPer la distribuzione su **AWS Elastic Beanstalk** viene solitamente utilizzata la CLI EB, la pipeline sar\u00e0 simile, ma con i comandi `eb deploy`.<\/p>\n\n\n\n
\ud83d\udd35 Distribuzione su Google Cloud Platform (GCP App Engine)<\/h3>\n\n\n\n
\ud83d\udd10 Segreti GitHub:<\/strong> GCP_CREDENTIALS<\/code> (chiave JSON dell’account di servizio), GCP_PROJECT_ID<\/code>.<\/p>\n\n\n\n# .github\/workflows\/deploy-gcp-app-engine.yml\nname: Deploy to GCP App Engine\n\non:\n push:\n branches: [main]\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v3\n - name: Set up Cloud SDK\n uses: google-github-actions\/setup-gcloud@v2\n with:\n project_id: ${{ secrets.GCP_PROJECT_ID }}\n service_account_key: ${{ secrets.GCP_CREDENTIALS }}\n export_default_credentials: true\n - name: Deploy to App Engine\n # Assicurati di avere app.yaml nella root del progetto\n run: gcloud app deploy --quiet<\/code><\/pre>\n\n\n\n\ud83d\udfea Distribuzione su Render.com<\/h4>\n\n\n\n
Render spesso distribuisce automaticamente al push su GitHub, se il repository \u00e8 connesso. Ma per un trigger manuale (o come parte di una pipeline pi\u00f9 complessa) \u00e8 possibile utilizzare un Deploy Hook.
\ud83d\udd10 Segreti GitHub:<\/strong> RENDER_DEPLOY_HOOK<\/code> (URL ottenuto dalle impostazioni del servizio Render).<\/p>\n\n\n\n# .github\/workflows\/deploy-render.yml\nname: Trigger Render Deploy\n\non:\n workflow_dispatch: # Avvio manuale dall'interfaccia utente di GitHub\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n steps:\n - name: Trigger Render Deploy Hook\n run: curl -X POST ${{ secrets.RENDER_DEPLOY_HOOK }}<\/code><\/pre>\n\n\n\n\ud83c\udf1f CI\/CD avanzato: Build Docker \u2192 Push su GHCR \u2192 Staging\/Production su GCP Cloud Run<\/h3>\n\n\n\n
E ora la ciliegina sulla torta! Costruiamo una pipeline avanzata: 1. Build dell’immagine Docker. 2. Pubblicazione dell’immagine nel GitHub Container Registry (ghcr.io). 3. Distribuzione automatica nell’ambiente di **staging** su GCP Cloud Run. 4. Distribuzione nell’ambiente di **produzione** su GCP Cloud Run **dopo conferma manuale**.<\/p>\n\n\n\n
Per questo, avremo bisogno di diversi file di workflow.<\/p>\n\n\n\n
Segreti GitHub richiesti:<\/strong><\/p>\n\n\n\n\n- `GCP_PROJECT_ID`: ID del tuo progetto GCP.<\/li>\n\n\n\n
- `GCP_CREDENTIALS`: Chiave JSON dell’account di servizio GCP con autorizzazioni per la distribuzione su Cloud Run e l’accesso a GHCR (se necessario). Di solito `GITHUB_TOKEN` \u00e8 sufficiente per l’accesso a GHCR da Actions.<\/li>\n\n\n\n
- `GCP_REGION`: Regione per Cloud Run (ad esempio, `europe-west1`).<\/li>\n<\/ul>\n\n\n\n
1. Build e pubblicazione dell’immagine Docker su GHCR<\/h3>\n\n\n\n# .github\/workflows\/build.yml\nname: Build & Push to GHCR\n\non:\n push:\n branches: [main] # Esegui al push su main\n\njobs:\n build-and-push:\n runs-on: ubuntu-latest\n permissions:\n contents: read # Per checkout\n packages: write # Per push su GHCR\n\n steps:\n - uses: actions\/checkout@v3\n\n - name: Log in to GitHub Container Registry\n uses: docker\/login-action@v3\n with:\n registry: ghcr.io\n username: ${{ github.actor }}\n password: ${{ secrets.GITHUB_TOKEN }}\n\n - name: Build and push Docker image\n uses: docker\/build-push-action@v5\n with:\n context: .\n push: true\n tags: ghcr.io\/${{ github.repository_owner }}\/${{ github.event.repository.name }}\/myapp:latest\n # Puoi aggiungere un tag per SHA del commit per l'unicit\u00e0:\n # tags: |\n # ghcr.io\/${{ github.repository_owner }}\/${{ github.event.repository.name }}\/myapp:latest\n # ghcr.io\/${{ github.repository_owner }}\/${{ github.event.repository.name }}\/myapp:${{ github.sha }}\n<\/code><\/pre>\n\n\n\n\n- `github.repository_owner`: Proprietario del repository (il tuo username o organizzazione).<\/li>\n\n\n\n
- `github.event.repository.name`: Nome del repository.<\/li>\n\n\n\n
- `myapp`: Nome della tua applicazione\/immagine.<\/li>\n<\/ul>\n\n\n\n
2. Distribuzione automatica su Staging (GCP Cloud Run)<\/h3>\n\n\n\n
Questo workflow verr\u00e0 eseguito automaticamente dopo il completamento con successo di `build.yml`.<\/p>\n\n\n\n
# .github\/workflows\/deploy-staging.yml\nname: Deploy to GCP Cloud Run (Staging)\n\non:\n workflow_run:\n workflows: ["Build & Push to GHCR"]\n types:\n - completed\n\njobs:\n deploy-staging:\n runs-on: ubuntu-latest\n if: ${{ github.event.workflow_run.conclusion == 'success' }}\n\n environment:\n name: staging\n url: ${{ steps.deploy.outputs.url }}\n\n steps:\n - uses: actions\/checkout@v3\n\n - id: 'auth'\n uses: 'google-github-actions\/auth@v2'\n with:\n credentials_json: '${{ secrets.GCP_CREDENTIALS }}'\n\n - name: 'Deploy to Cloud Run (Staging)'\n id: deploy\n uses: 'google-github-actions\/deploy-cloudrun@v2'\n with:\n service: 'myapp-staging'\n region: '${{ secrets.GCP_REGION }}'\n image: 'ghcr.io\/${{ github.repository_owner }}\/${{ github.event.repository.name }}\/myapp:latest'\n project_id: '${{ secrets.GCP_PROJECT_ID }}'\n flags: '--allow-unauthenticated --platform=managed'\n<\/code><\/pre>\n\n\n\n3. Distribuzione in produzione con conferma manuale (GCP Cloud Run)<\/h3>\n\n\n\n
Questo workflow viene attivato manualmente tramite l’interfaccia utente di GitHub Actions.<\/p>\n\n\n\n
# .github\/workflows\/deploy-prod.yml\nname: Deploy to GCP Cloud Run (Production)\n\non:\n workflow_dispatch: # Consente l'avvio manuale\n\njobs:\n deploy-production:\n runs-on: ubuntu-latest\n\n environment:\n name: production\n url: ${{ steps.deploy.outputs.url }}\n\n steps:\n - uses: actions\/checkout@v3\n\n - id: 'auth'\n uses: 'google-github-actions\/auth@v2'\n with:\n credentials_json: '${{ secrets.GCP_CREDENTIALS }}'\n\n - name: 'Deploy to Cloud Run (Production)'\n id: deploy\n uses: 'google-github-actions\/deploy-cloudrun@v2'\n with:\n service: 'myapp-production'\n region: '${{ secrets.GCP_REGION }}'\n image: 'ghcr.io\/${{ github.repository_owner }}\/${{ github.event.repository.name }}\/myapp:latest'\n project_id: '${{ secrets.GCP_PROJECT_ID }}'\n flags: '--allow-unauthenticated --platform=managed'\n # Per la produzione puoi aggiungere --no-traffic e poi spostare gradualmente il traffico\n # traffic:\n # latest: true\n # percent: 100\n<\/code><\/pre>\n\n\n\nPunti importanti di questa pipeline avanzata:<\/h3>\n\n\n\n\n- GitHub Container Registry (ghcr.io):<\/strong> Lo usiamo per archiviare le immagini Docker. \u00c8 comodo perch\u00e9 \u00e8 strettamente integrato con GitHub Actions.<\/li>\n\n\n\n
workflow_run<\/code>:<\/strong> Consente di eseguire un workflow (distribuzione di staging) al completamento di un altro (build).<\/li>\n\n\n\nworkflow_dispatch<\/code>:<\/strong> Offre la possibilit\u00e0 di attivare manualmente un workflow (distribuzione di produzione), garantendo il controllo.<\/li>\n\n\n\n- GitHub Environments:<\/strong> Ti consentono di configurare regole di protezione per la produzione (ad esempio, richiedere l’approvazione di revisori specifici) e di archiviare segreti specifici dell’ambiente.<\/li>\n\n\n\n
- GCP Cloud Run:<\/strong> Un’ottima opzione serverless per eseguire applicazioni containerizzate.<\/li>\n<\/ul>\n\n\n\n
\ud83d\udd10 Sicurezza \u2013 \u00e8 importante!<\/h3>\n\n\n\n\n- Usa i segreti GitHub:<\/strong> Non archiviare mai token, password, chiavi API direttamente nei file YAML. Usa `Settings -> Secrets and variables -> Actions` nel tuo repository.<\/li>\n\n\n\n
- Privilegi minimi:<\/strong> Per gli account di servizio (ad esempio, GCP), concedi solo le autorizzazioni strettamente necessarie per l’esecuzione delle attivit\u00e0 CI\/CD.<\/li>\n\n\n\n
- Isola gli ambienti:<\/strong> Staging e produzione dovrebbero essere il pi\u00f9 isolati possibile. Progetti\/account diversi nei provider cloud sono una buona pratica.<\/li>\n\n\n\n
- Protezione dei branch:<\/strong> Configura la protezione per il branch `main` (o `master`) in modo che i push siano possibili solo tramite Pull Request con controlli CI obbligatori.<\/li>\n<\/ul>\n\n\n\n
\ud83d\ude80 CI\/CD: Dalle basi alla produzione su GCP con GitHub Actions \u2013 Una guida completa con esempi<\/strong> \ud83d\ude80<\/p>\n\n\n\nCiao, sviluppatori! In questo articolo parler\u00f2 di CI\/CD \u2013 un concetto.<\/p>\n\n\n\n
Cos’\u00e8 una pipeline CI\/CD nel contesto della programmazione?<\/h3>\n\n\n\n
Una pipeline CI\/CD (Continuous Integration \/ Continuous Delivery o Continuous Deployment)<\/strong> \u00e8 un processo automatizzato che consente agli sviluppatori di consegnare rapidamente e in modo affidabile le modifiche al codice in un ambiente di produzione.<\/p>\n\n\n\nAnalizziamo i concetti chiave:<\/p>\n\n\n\n
\ud83d\udd27 CI \u2014 Continuous Integration (Integrazione Continua)<\/strong>
Questa \u00e8 una pratica in cui gli sviluppatori integrano frequentemente le modifiche in una codebase condivisa. Ogni modifica di questo tipo viene automaticamente: * Costruita<\/strong> (build) * Testata<\/strong> (test unitari, test di integrazione) * Verificata per la conformit\u00e0 agli standard<\/strong> (linting, analisi statica)<\/p>\n\n\n\n\ud83d\udc49 **Obiettivo della CI:** Identificare gli errori il prima possibile, prima che rompano qualcosa di importante o finiscano in una release.<\/p>\n\n\n\n
\ud83d\ude80 **CD \u2014 Continuous Delivery (Consegna Continua) o Continuous Deployment (Distribuzione Continua)**
Qui ci sono due opzioni:<\/p>\n\n\n\n
\u2705 **Continuous Delivery (Consegna Continua)**
Dopo il successo della fase CI, le modifiche vengono automaticamente: * Sottoposte a test aggiuntivi (ad esempio, test E2E \u2013 end-to-end) * Distribuite su un server di staging (test)<\/p>\n\n\n\n
\ud83d\udc49 **Ma la distribuzione in produzione richiede ancora una conferma manuale.** Questo d\u00e0 al team il controllo su *quando* esattamente gli utenti vedranno le modifiche.<\/p>\n\n\n\n
\ud83e\udd16 **Continuous Deployment (Distribuzione Continua)**
Questo \u00e8 il passo successivo dopo la Continuous Delivery. Qui, la distribuzione in produzione avviene **completamente automaticamente**, se tutte le fasi precedenti della pipeline (build, tutti i test) sono state completate con successo. Questo \u00e8 il livello pi\u00f9 avanzato di automazione.<\/p>\n\n\n\n
\ud83d\udd04 Di cosa \u00e8 composta di solito una pipeline CI\/CD?<\/h3>\n\n\n\n
Una pipeline tipica include le seguenti fasi:<\/p>\n\n\n\n
\n- Checkout<\/strong> \u2014 Clonazione dell’ultima versione del codice dal repository.<\/li>\n\n\n\n
- Build<\/strong> \u2014 Costruzione del progetto (compilazione, assemblaggio di artefatti, immagini Docker).<\/li>\n\n\n\n
- Test<\/strong> \u2014 Esecuzione di vari tipi di test (unitari, di integrazione, E2E).<\/li>\n\n\n\n
- Lint\/Code Quality<\/strong> \u2014 Controllo del codice per la conformit\u00e0 allo stile e potenziali errori utilizzando analizzatori statici.<\/li>\n\n\n\n
- Deploy<\/strong> \u2014 Distribuzione dell’applicazione (su un server di staging o di produzione).<\/li>\n\n\n\n
- Notify<\/strong> \u2014 Invio di notifiche sullo stato della pipeline al team (ad esempio, in Slack, Email).<\/li>\n<\/ol>\n\n\n\n
\ud83d\udee0 Strumenti popolari per CI\/CD:<\/h3>\n\n\n\n\n- GitHub Actions<\/strong> (il nostro focus oggi!)<\/li>\n\n\n\n
- GitLab CI\/CD<\/li>\n\n\n\n
- Jenkins<\/li>\n\n\n\n
- CircleCI<\/li>\n\n\n\n
- Bitbucket Pipelines<\/li>\n\n\n\n
- Azure DevOps<\/li>\n\n\n\n
- TeamCity<\/li>\n<\/ul>\n\n\n\n
\ud83e\udde0 Perch\u00e9 abbiamo bisogno di CI\/CD?<\/h3>\n\n\n\n\n- Riduce l’errore umano:<\/strong> L’automazione elimina gli errori associati alle operazioni manuali.<\/li>\n\n\n\n
- Rilevamento rapido dei bug:<\/strong> Gli errori vengono trovati prima, rendendoli pi\u00f9 facili e meno costosi da correggere.<\/li>\n\n\n\n
- Automazione delle attivit\u00e0 di routine:<\/strong> Gli sviluppatori dedicano meno tempo alla costruzione e alla distribuzione e pi\u00f9 tempo alla codifica.<\/li>\n\n\n\n
- Miglioramento della qualit\u00e0 del codice:<\/strong> Controlli e test continui aumentano il livello di qualit\u00e0 complessivo.<\/li>\n\n\n\n
- Consegna rapida delle funzionalit\u00e0 agli utenti:<\/strong> Le nuove funzionalit\u00e0 raggiungono l’utente finale pi\u00f9 rapidamente e pi\u00f9 frequentemente.<\/li>\n<\/ul>\n\n\n\n
\ud83d\udce6 Esempi semplici di CI\/CD con GitHub Actions<\/h3>\n\n\n\n
Diamo un’occhiata alle pipeline di base per le tecnologie pi\u00f9 diffuse. Tutti gli esempi utilizzano GitHub Actions e vengono salvati nella directory