{
    "version": "https://jsonfeed.org/version/1",
    "title": "Nimbiora Consulting IT",
    "description": "",
    "home_page_url": "https://www.nimbiora.com/it",
    "feed_url": "https://www.nimbiora.com/it/feed.json",
    "user_comment": "",
    "icon": "https://www.nimbiora.com/it/media/website/logo-nimbiora-consulting-side-white-fix.png",
    "author": {
        "name": "Luigi Clemente"
    },
    "items": [
        {
            "id": "https://www.nimbiora.com/it/blog/github-actions-pipeline-per-la-landing-zone/",
            "url": "https://www.nimbiora.com/it/blog/github-actions-pipeline-per-la-landing-zone/",
            "title": "Github Actions Pipeline per la Landing Zone",
            "summary": "Abbiamo rilasciato una funzionalità che migliora il modo in cui distribuiamo e gestiamo la nostra piattaforma cloud: una pipeline GitHub Actions progettata specificamente per il workflow della nostra Landing Zone. Si tratta di una pipeline strutturata di delivery dell’infrastruttura, realizzata per supportare operazioni AWS multi-account,&hellip;",
            "content_html": "<p>Abbiamo rilasciato una funzionalità che migliora il modo in cui distribuiamo e gestiamo la nostra piattaforma cloud: una pipeline GitHub Actions progettata specificamente per il workflow della nostra Landing Zone.<br><br>Si tratta di una pipeline strutturata di delivery dell’infrastruttura, realizzata per supportare operazioni AWS multi-account, ridurre il rischio operativo e mantenere i deployment prevedibili man mano che la piattaforma cresce.<br><br>Ad alto livello, la pipeline automatizza l’intero ciclo di vita delle modifiche infrastrutturali. Ogni aggiornamento segue una sequenza di validazione, pianificazione, approvazione controllata e deployment. Codificando questi passaggi in GitHub Actions, abbiamo eliminato il problema del “sul mio computer funziona” e definito un percorso unico e affidabile dalla pull request a modifiche infrastrutturali pronte per la produzione.<br><br>Un obiettivo progettuale fondamentale era l’automazione security-first. La pipeline è costruita su credenziali a breve durata, così evitiamo segreti a lunga durata e pattern di accesso non controllati. Questo ci permette di mantenere agilità negli aggiornamenti  preservando al tempo stesso una governance solida.<br><br>Il workflow è trasparente: le pull request producono output di plan chiari, così i reviewer possono vedere esattamente cosa cambierà prima di applicare qualunque modifica. Questo migliora la collaborazione tra i gestori della piattaforma e della sicurezza, perché le discussioni si basano su risultati di esecuzione concreti. Il risultato sono review più rapide e meno sorprese durante il deployment.</p>\n<p>Per una sicurezza maggiore, dato il divario temporale tra plan e apply, preveniamo possibili drift tra revisione ed esecuzione: gli approvatori devono approvare esattamente il change set che verrà applicato. Il plan viene generato per primo nel job <code>plan-for-apply</code>, il workflow normalizza l’output del plan e poi calcola un hash SHA256. Questo hash viene esposto come <code>overall_plan_sha</code> e mostrato nell'output del workflow. La pipeline si ferma dopo il plan e indica all’operatore di eseguire l’apply solo su un piano che abbia l’hash del plan atteso. Se gli hash differiscono, l’apply viene bloccato.<br><br>Dal punto di vista ingegneristico, questa pipeline offre una base che può evolvere nel tempo. Oggi impone un processo di rilascio più sicuro e ripetibile. Domani può supportare livelli aggiuntivi, come controlli di drift schedulati, validazioni di policy più ricche, verifiche di cost-awareness, strategie di rollout specifiche per ambiente e reportistica dei cambiamenti più robusta per scenari di audit e compliance. In altre parole, non è solo automazione per i task di oggi, ma una piattaforma per una maturità operativa futura.<br><br>Ancora più importante, questa funzionalità cambia il modo in cui il team lavora. Se scegliete questo approccio, passate da un’esecuzione manuale e dipendente dall’operatore a un flusso di delivery codificato, revisionabile e scalabile. Questo cambiamento aumenta l’affidabilità, migliora la postura di sicurezza e libera tempo per attività di piattaforma a maggior valore.<br><br>Questo è un passo importante nel nostro percorso Landing Zone: delivery più veloce, modifiche infrastrutturali più sicure e un workflow che scala con l’organizzazione.</p>\n<p>Scopri di piu sulla <a href=\"https://www.nimbiora.com/it/nimbiora-aws-landing-zone/\">Nimbiora Landing Zone</a>.</p>",
            "author": {
                "name": "Luigi Clemente"
            },
            "tags": [
                   "novità",
                   "landing zone",
                   "features"
            ],
            "date_published": "2026-05-26T15:53:40+02:00",
            "date_modified": "2026-05-26T16:06:08+02:00"
        },
        {
            "id": "https://www.nimbiora.com/it/blog/workload-account-creation-wizard/",
            "url": "https://www.nimbiora.com/it/blog/workload-account-creation-wizard/",
            "title": "Workload Account Creation Wizard",
            "summary": "Lancia nuovi workload AWS account in totale sicurezza grazie a una procedura guidata, progettata per semplificare la gestione e scalabilità della landing zone. Il wizard accompagna i team lungo l’intero flusso di onboarding dell’account, dalla registrazione nell’organizzazione e dalla configurazione della baseline fino al networking&hellip;",
            "content_html": "<p><strong>Lancia nuovi workload AWS account</strong> in totale sicurezza grazie a una procedura guidata, progettata per semplificare la gestione e scalabilità della landing zone.<br><br>Il wizard accompagna i team lungo l’intero flusso di onboarding dell’account, dalla registrazione nell’organizzazione e dalla configurazione della baseline fino al networking e alla connettività, garantendo un’esecuzione sicura in ogni passaggio, pensato per il team operations che ha bisogno di automazione.</p>\n<h2>Funzionalità principali</h2>\n<ul>\n<li><strong>Flusso guidato end-to-end</strong>: copre la creazione dell'account, il provisioning della baseline, del networking e configurazioni successive.</li>\n<li><strong>Checkpoint e restore</strong>: ogni fase viene tracciata, cosi le esecuzioni interrotte possono ripartire esattamente dal punto in cui si erano fermate.</li>\n<li><strong>Richiesta di conferma</strong>: le azioni di terraform <em>apply</em> devono essere confermate esplicitamente dall’operatore, con prompt di conferma predefinita per velocizzare.</li>\n<li><strong>Esecuzione standardizzata</strong>: utilizza comandi basati su Make coerenti per mantenere i flussi prevedibili tra ambienti diversi.</li>\n<li><strong>Configurazione identity-first</strong>: gestisce la generazione dei profili SSO e i prerequisiti di login prima del provisioning finale del workload account.</li>\n<li><strong>Opzioni di connettività</strong>: supporta i diversi modelli di rete inclusi nella landing zone: VPC peering o transit gateway.</li>\n<li><strong>Progettato per scalare</strong>: funziona come processo ripetibile di account factory per organizzazioni multi-account in crescita.</li>\n</ul>\n<p>Scopri di piu sulla <a href=\"https://www.nimbiora.com/it/nimbiora-aws-landing-zone/\">Nimbiora Landing Zone</a>.</p>",
            "author": {
                "name": "Luigi Clemente"
            },
            "tags": [
                   "novità",
                   "landing zone",
                   "features"
            ],
            "date_published": "2026-05-26T14:50:51+02:00",
            "date_modified": "2026-05-26T16:06:20+02:00"
        }
    ]
}
