{"id":98,"date":"2017-03-10T15:33:42","date_gmt":"2017-03-10T14:33:42","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=98"},"modified":"2023-02-22T17:22:28","modified_gmt":"2023-02-22T16:22:28","slug":"full-stack-continuous-delivery-su-aws","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/full-stack-continuous-delivery-su-aws\/","title":{"rendered":"Full stack Continuous Delivery su AWS"},"content":{"rendered":"

Con il lancio di CodeBuild<\/a> avvenuto lo scorso novembre sul palco del re:Invent<\/a>, AWS ha aggiunto il tassello mancante alla suite di strumenti gestione del ciclo di sviluppo del software<\/span><\/p>\n

Noi c\u2019eravamo<\/a> e non aspettavamo altro per poterci mettere all\u2019opera e implementare finalmente un sistema di Continuous Delivery interamente basato su servizi gestiti da Amazon Web Services<\/strong>.<\/p>\n

<\/p>\n

Prima di CodeBuild, infatti, la suite di AWS copriva unicamente gli aspetti relativi al source control (CodeCommit<\/a>), alla gestione dei rilasci (CodeDeploy<\/a>) e all\u2019orchestrazione (CodePipeline<\/a>), costringendo gli sviluppatori ad utilizzare tool di terze parti (ad esempio Jenkins<\/a>) per la gestione delle fasi di build e test. Tool che vanno configurati e gestiti manualmente, con tutte le problematiche che ne conseguono in termini di complessit\u00e0, costi e affidabilit\u00e0 della soluzione.<\/span><\/p>\n

Pensiamo infatti a quanto lo stack di Continuous Delivery\u00a0da un lato sia critico (un inconveniente a questi tool pu\u00f2 compromettere ore o giorni di lavoro di un intero team di sviluppo), ma dall\u2019altro rappresenti, specie per team DevOps piccoli e agili, un oggetto estraneo alle attivit\u00e0 \u201ccore\u201d, su cui concentrare il minor sforzo possibile; una sorta di <\/strong><\/span>black-box<\/i> che deve semplicemente funzionare. <\/strong><\/p>\n

Uno stack di Continuous Delivery deve:<\/span><\/p>\n