A poco pi\u00f9 di 9 anni dopo (il 31 Luglio 2024) siamo venuti a conoscenza che questa abitudine dovr\u00e0 cambiare a seguito dell\u2019annuncio di Jeff Barr su X. <\/p>\n\n\n\n
<\/p>\n\n\n
![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/02\/image1-2.png\")
<\/figure><\/div>\n\n\n<\/p>\n\n\n\n
La notizia ha colto tutti di sorpresa: in sostanza, tutti gli account AWS aperti dopo il 31 Luglio 2024 non potranno pi\u00f9 accedere al servizio, mentre gli account parte di una Organization in cui erano gi\u00e0 presenti repository potranno continuare as accedervi normalmente.
Il servizio non \u00e8 per\u00f2 in fase di dismissione, come era stato ipotizzato nei giorni successivi all\u2019annuncio; sono garantiti gli aggiornamenti di sicurezza, la risoluzione dei bug e la manutenzione, ma non verranno sviluppate nuove feature.<\/p>\n\n\n\n
Nonostante fosse un servizio che non offriva opzioni avanzate per la collaborazione collettiva, la sua forza stava nell\u2019integrazione con i vari strumenti di automazione e rilascio offerti da AWS (come ad esempio CodePipeline, CodeDeploy ed Amplify).<\/p>\n\n\n\n
Sulle motivazioni che hanno portato AWS a prendere questa decisione sono gi\u00e0 state fatte molte discussioni. Il nostro obiettivo \u00e8 invece quello di vagliare le differenti alternative disponibili, mettendo in luce pro e contro in base anche ai differenti scenari.<\/p>\n\n\n\n
Per poter decidere quale soluzione possa sostituirlo al meglio, capiamo prima quali erano i punti di forza e le mancanze di AWS CodeCommit.<\/p>\n\n\n\n
Perch\u00e8 AWS CodeCommit era comodo <\/h1>\n\n\n\n
AWS CodeCommit era sicuramente uno dei servizi pi\u00f9 facili e intuitivi tra quelli offerti da AWS e la sua integrazione nativa con AWS CodePipeline rendeva lo sviluppo di tutto il comparto CI\/CD molto pi\u00f9 immediato e leggero.<\/p>\n\n\n\n
Un setup intuitivo e veloce, permetteva agli sviluppatori di concentrarsi principalmente sul codice applicativo, ma senza rinunciare alla funzionalit\u00e0 di rilascio continuo e testing. Basta pensare che tutti i linguaggi di IaC supportano direttamente la configurazione di pipeline con uno step di source direttamente integrato con il repository.<\/p>\n\n\n\n
Un altro aspetto che semplificava molto l\u2019operativit\u00e0 era l\u2019integrazione con IAM, che forniva la possibilit\u00e0 di gestire i permessi Git utilizzando gli utenti gi\u00e0 censiti: era possibile definire le git Operations (Pull, push, merge\u2026) consentite agli utenti direttamente all\u2019interno delle policy IAM, risultando veloce e di facile gestione.\u00a0<\/p>\n\n\n\n
Era anche possibile realizzare flussi di notifica e approvazione direttamente integrati con il Cloud AWS (ad esempio Amazon SNS, Amazon EventBridge), mentre cambiando Git provider, potrebbe rendersi necessario realizzare integrazioni non pi\u00f9 direttamente configurabili su AWS.<\/p>\n\n\n\n
Inoltre, il costo del servizio era davvero irrisorio e permetteva a chiunque di approcciarsi senza doversi districare fra le feature offerte da una selva di piani di utilizzo differenti.<\/p>\n\n\n\n
Un ultimo aspetto, ma molto importante, era la sua integrazione nella Landing Zone AWS, che permette di avere una governance unica di tutti i servizi. <\/p>\n\n\n\n
In questo modo, quindi, anche l\u2019accesso ai repository ed i permessi potevano essere definiti utilizzando IAM, facilitando cos\u00ec i controlli e le review ed accentrando di fatto il controllo in un unico punto centralizzato che pu\u00f2 essere federato con l\u2019IdP aziendale.<\/p>\n\n\n\n
Tutte queste caratteristiche hanno aiutato non solo le realt\u00e0 pi\u00f9 strutturate, ma anche le startup e imprese pi\u00f9 piccole. Il non dover dipendere da altri team di gestione per strumenti \u201ccorporate\u201d, l\u2019integrazione e il basso costo hanno infatti permesso la nascita e il test di molti progetti, facilitando la sperimentazione e sposando perfettamente il principio del \u201cfail-fast\u201d tipico del Cloud, entrambi punti fondamentali della filosofia di AWS che mira ad abilitare sempre pi\u00f9 \u201cbuilder\u201d a mettere a terra soluzioni innovative velocemente. <\/p>\n\n\n\n
Debolezze<\/h2>\n\n\n\n
Nonostante tutti gli aspetti positivi descritti, era innegabile che AWS CodeCommit avesse alcun limiti abbastanza evidenti.<\/p>\n\n\n\n
Il primo tra tutti era il ridotto numero di integrazioni con elementi esterni ad AWS. Al giorno d\u2019oggi \u00e8 essenziale per uno strumento di code repository fornire svariate integrazioni oltre a gestire branch e risolvere conflitti. Ormai praticamente tutti i vendor pi\u00f9 famosi offrono soluzioni direttamente integrate con prodotti di terze parti per poter offrire all\u2019utente un esperienza a 360\u00b0 sulle loro piattaforme.<\/p>\n\n\n\n
Il secondo aspetto critico era la scarsa implementazione di feature per lo sviluppo e le review collaborative. Anche se la possibilit\u00e0 di effettuare \u201cpull & merge request\u201d era presente, la loro implementazione era molto basilare. Per non parlare della user experience; ad oggi, gli strumenti di sviluppo collaborativo offrono interfacce utente molto pi\u00f9 pulite, pur offrendo numerosissime feature anche molto complesse e avanzate per review e comparazione di codice.<\/p>\n\n\n\n
Riflettendo sull\u2019annuncio si pu\u00f2 pensare quindi che la strategia di AWS non fosse quella di competere con i big player offrendo un servizio sostitutivo e completo, ma di offrire un\u2019opzione integrata in un\u2019ottica di governance centralizzata degli account e delle risorse.<\/p>\n\n\n\n
Codebases alternative: GitHub, Gitlab, Bitbucket <\/h1>\n\n\n\n
Come abbiamo gi\u00e0 detto, AWS CodeCommit non \u00e8 pi\u00f9 disponibile per i nuovi arrivati su AWS, ma il servizio non \u00e8 in dismissione: non \u00e8 necessario pensare a strategie di emergenza, ma bisogna comunque iniziare a valutare tra le diverse opzioni disponibili.<\/p>\n\n\n\n
Prima di tutto dobbiamo capire quale, tra le tante scelte, \u00e8 quella che pi\u00f9 si adatta alle nostre esigenze e risorse.<\/p>\n\n\n\n
AWS suggerisce direttamente alcuni vendor, tra cui troviamo i pi\u00f9 famosi GitHub<\/strong>, GitLab<\/strong> e BitBucket<\/strong>. Il driver principale dietro a questo suggerimento \u00e8 proprio – di nuovo – l\u2019integrazione tra queste piattaforme e i servizi AWS.<\/strong><\/p>\n\n\n\n L\u2019ago della bilancia pu\u00f2 essere spostato da una semplice domanda:\u00a0<\/p>\n\n\n\n \u201cqual\u2019\u00e8 l\u2019utilizzo effettivo del mio repository?\u201d<\/p>\n\n\n\n Cercheremo di abbinare le risposte pi\u00f9 comuni a questa domanda con i vari prodotti disponibili sul mercato.<\/p>\n\n\n\n Tra i nomi citati prima, \u00e8 naturale che l\u2019occhio ricada sui due colossi presenti nella lista: GitHub e GitLab. Dato il loro elevato utilizzo, sono veramente pochi i servizi (AWS e non) con i quali queste piattaforme non offrono un\u2019integrazione. Tutte e tre le soluzioni possono essere configurate direttamente come step di source per AWS CodePipeline attraverso la creazione di una CodeStar connection. In questo caso, sia per GitHub che per GitLab, possiamo utilizzare la versione SaaS o quella self-hosted.<\/p>\n\n\n\n Se intendiamo approcciare una di queste soluzioni, viene anche naturale porsi la domanda \u201cho veramente bisogno di AWS CodePipeline?\u201d.<\/p>\n\n\n\n Se prima utilizzavamo AWS CodeCommit perch\u00e9 comodo e presente nella stessa conosole di AWS CodePipeline, ora che dovremo utilizzare un altro servizio esterno potrebbe non valere pi\u00f9 la pena di usare le pipeline di AWS.<\/p>\n\n\n\n Sia GitHub che Gitlab, ma anche BitBucket, offrono il loro servizio di pipeline integrate. Rispetto ad AWS questi servizi sono costruiti per sfruttare le tecnologie pi\u00f9 disparate e i prodotti di terze parti pi\u00f9 comuni. Adottare questo tipo di Pipeline potrebbe agevolare tutti quegli step intermedi che spesso dovevano essere orchestrati con complessi automatismi di AWS CodeBuild.<\/p>\n\n\n\n Al contempo, l\u2019effort di sviluppo degli strumenti dedicati alla developer experience su AWS si \u00e8 spostato ed offre integrazioni migliori, come nel caso di GitLab: \u00e8 possibile ora configurare i runner utilizzando AWS CodeBuild come piattaforma di compute, permettendo di impostare un controllo dei permessi pi\u00f9 granulare rispetto al passato per interagire con le risorse cloud. A chi non \u00e8 mai capitato di vedere runner su EC2 che avevano effettivamente i permessi di AdministratorAccess? <\/p>\n\n\n\n Anche le GitHub actions ora sono integrate, ed \u00e8 appena stata annunciata l\u2019integrazione con BuildKite.<\/p>\n\n\n\n Esiste anche poi l\u2019alternativa \u201chomemade\u201d: anche un mero repository Git accessibile via ssh ha la possibilt\u00e0 di invocare hook e compiere azioni, ma gestire in autonomia il proprio repository, spendendo tempo per garantire l\u2019alta affidabilit\u00e0, la sicurezza ed effettuare le manutenzioni non porta benefici rispetto all\u2019utilizzo di servizi gestiti che garantiscono gi\u00e0 questi aspetti e che permettono invece di concentrarsi sulle\u00a0 vere esigenze di business. Questa ipotesi non \u00e8 comunque da escludere per requisiti e casi molto particolari.<\/p>\n\n\n\n Dopo l\u2019annuncio di Jeff Bar<\/a> di alcuni mesi fa, in molti avranno pensato di dover correre ai ripari scegliendo in fretta e furia una nuova codebase.<\/p>\n\n\n\n In realt\u00e0 non si tratta di una dismissione del servizio, ma \u00e8 comunque giusto iniziare a valutare le diverse opzioni che il mercato ha da offrire come alternativa a un servizio che – almeno per chi ha un ecosistema su AWS – era diventato quasi uno standard.<\/p>\n\n\n\n Con i suoi PRO e CONTRO, AWS CodeCommit ci lascia un’importante eredit\u00e0 di insegnamenti riguardo alla gestione delle pipeline, utilissima durante il processo decisionale per la scelta di una valida alternativa:<\/p>\n\n\n\n Avere una console centralizzata per la gestione di accessi e configurazioni, ad esempio, \u00e8 fondamentale per mantenere la governance.<\/p>\n\n\n\n L’integrazione con gli IDP di terze parti \u00e8 un altro aspetto importante; molti Git-Repository si integrano ormai nativamente e permettono di configurare un meccanismo di SSO per fornire agli utenti un\u2019esperienza trasparente e agevolata nell\u2019utilizzo di un nuovo strumento.<\/p>\n\n\n\n Un altro punto importante riguarda la UX: quando si effettua un cambio di questo genere, il primo impatto sull\u2019usabilit\u00e0 di un prodotto ne decreta spesso un feedback positivo o negativo da parte degli utenti che dovranno approcciarsi a questo cambio.<\/p>\n\n\n\n Una volta scelta una nuova piattaforma, anche se tutto funziona sulla carta, \u00e8 consigliabile iniziare lo sviluppo dei nuovi progetti per prendere confidenza con gli strumenti offerti e pianificare quindi una migrazione graduale dei repository<\/a> gi\u00e0 esistenti in ottica di unificazione della gestione, eventualmente affiancati da un partner.<\/p>\n\n\n\n Avete gi\u00e0 riflettuto su quale strumento accoglier\u00e0 i vostri repository in futuro? Fatecelo sapere nei commenti!<\/p>\n\n\n\nIl \u201cfatto in casa\u201d<\/h4>\n\n\n\n
Conclusione<\/h1>\n\n\n\n
\n\n\n\nAbout Proud2beCloud<\/h4>\n\n\n\n