da poco \u00e8 disponibile un\u2019immagine di Codebuild MacOS<\/a><\/strong>.<\/p>\n\n\n\nPerch\u00e9 non esplorare subito questa nuova possibilit\u00e0? Quali vantaggi porta? Come si compara con ci\u00f2 che abbiamo fatto noi?<\/p>\n\n\n\n
A costo di tardare con l’uscita dell\u2019articolo, abbiamo deciso di integrare queste considerazioni ed eccoci qui con il contenuto che state leggendo ora.<\/p>\n\n\n\n
Senza ulteriori premesse, entriamo nel vivo dell’argomento partendo proprio dalla soluzione di AWS.\u2018<\/em>La maggior parte dei problemi citati qui sopra sono dovuti all’attuale immaturit\u00e0 del servizio che, essendo appena uscito, ha ancora delle limitazioni; limitazioni che sicuramente col tempo verranno mitigate.<\/em>\u2019<\/p>\n\n\n\nAWS CodeBuild per MacOS<\/h2>\n\n\n\n Con l\u2019uscita dell\u2019immagine Codebuild MacOS abbiamo adesso la possibilit\u00e0 di integrare in una Pipeline una macchina con sistema operativo MacOS<\/strong> senza dover creare metodi di integrazione custom e quindi facilitando di gran lunga la velocit\u00e0 di rilascio dell’infrastruttura. Questo \u00e8 sicuramente il primo grande vantaggio della soluzione di AWS.<\/p>\n\n\n\nMa vediamo con ordine tutti i pro e contro:<\/p>\n\n\n\n
PRO<\/h4>\n\n\n\n Serverless<\/strong><\/p>\n\n\n\nCodebuild \u00e8 gi\u00e0 predisposto all\u2019essere Serverless. Questo ci permetterebbe di avere sempre a disposizione una macchina per poter rilasciare le nostre applicazioni senza preoccuparci di un eventuale disservizio e senza dover gestire manualmente configurazioni per l\u2019alta affidabilit\u00e0.<\/p>\n\n\n\n
Cosa, quest\u2019ultima, che dovrebbe invece essere gestita in altre situazioni, per esempio avendo una seconda macchina in una differente \u2018Availability Zone\u2019.<\/p>\n\n\n\n
Gestione e costi<\/strong><\/p>\n\n\n\nCodebuild ci offre la possibilit\u00e0 di utilizzare la stessa Fleet per diversi progetti, e quindi poter ripartire le spese su pi\u00f9 applicazioni, diminuendone il singolo costo.<\/p>\n\n\n\n
Sar\u00e0 per\u00f2 necessario avere attenzione riguardo a come gestirne il setup e la sua configurazione in modo dinamico, cos\u00ec da utilizzare gli stessi script ad ogni lancio, cambiando solo delle variabili.<\/p>\n\n\n\n
Questo porter\u00e0 a lungo andare e su pi\u00f9 progetti vantaggi sia economici, che gestionali.<\/p>\n\n\n\n
CONTRO<\/h4>\n\n\n\n Una sola immagine<\/strong><\/p>\n\n\n\nLe immagini, o meglio, l\u2019immagine disponibile \u00e8 solamente una, con una versione ben specifica di XCode (Programma che serve per creare il file .IPA da poter poi rilasciare nell\u2019app store).<\/p>\n\n\n\n
Questo porta a diverse criticit\u00e0:<\/p>\n\n\n\n
\nNon avere sempre a disposizione l\u2019ultima versione del software<\/li>\n\n\n\n Non avere tutti i programmi installati (Come IXGuard)<\/li>\n\n\n\n Mantenere l\u2019ambiente di sviluppo in locale allineato con quello in cloud limitando gli sviluppatori ad utilizzare una versione specifica e perdendo gli aggiornamenti che portano maggiore sicurezza e velocit\u00e0.<\/li>\n<\/ul>\n\n\n\nCosti fissi<\/strong><\/p>\n\n\n\nQuesta versione specifica di CodeBuild ha una modalit\u00e0 di pagamento differente dal classico pay-per-use tipico delle immagini pi\u00f9 comuni (Come quelle Linux). <\/p>\n\n\n\n
La differenza deriva dall\u2019avere come hardware una macchina MAC fisica, il che richieder\u00e0 di dover creare una Codebuild Fleet; la quale avr\u00e0 un costo anche se non utilizzata attivamente. <\/p>\n\n\n\n
Questo non dovrebbe essere un grosso problema, dato che l\u2019alternativa \u00e8 una istanza MAC fisica\u2026purtroppo per\u00f2 il costo di Codebuild \u00e8 maggiore rispetto a quello di una istanza EC2, specialmente se con dei saving plan a lungo termine.<\/p>\n\n\n\n
Complessit\u00e0<\/strong><\/p>\n\n\n\nPersonalmente mi aspettavo fossero integrati alcuni script di uso comune per lo sviluppo di un’app all\u2019interno dell\u2019immagine di Codebuild. Sarebbe stato cos\u00ec pi\u00f9 facile svolgere alcune operazioni necessarie, come la configurazione e l\u2019installazione dei \u2018provisioning profile\u2019, i quali sono richiesti per rilasciare un\u2019applicazione nell\u2019AppStore. <\/p>\n\n\n\n
\u00c8 quindi necessario crearne alcuni in autonomia.<\/p>\n\n\n\n
Da poco AWS ci fornisce un ulteriore strumento, ovvero la diretta integrazione tra CodeBuild e GitLab Runners. Questo potrebbe risultare utile quando vi \u00e8 gia\u2019 un ambiente GitLab per il proprio Software Version Control. In questo caso sarebbe quindi possibile integrare il tutto direttamente tra i due providers, riducendo il costo e gestendo con pi\u00f9 facilit\u00e0 l\u2019istanza tramite GitLab.<\/p>\n\n\n\n
La nostra soluzione<\/h2>\n\n\n\n “Ai nostri tempi…”, ovvero qualche mese fa, non avevamo niente per poter gestire in modo autonomo la creazione di un’applicazione iOS, dunque abbiamo cercato di capire dove fosse possibile integrare automatismi e quali.<\/p>\n\n\n\n
Tutto questo pensare, oltre che farci venire fame e sete, ci ha portato ad una soluzione 100% personalizzata che \u00e8 attualmente in uso.<\/p>\n\n\n\n
Siccome uno dei prerequisiti del cliente era mantenere tutto sullo stesso ambiente AWS<\/strong>, non abbiamo potuto utilizzare le GitHub actions, che avrebbero facilitato la nostra integrazione con l\u2019ambiente iOS. Questo perch\u00e9 sono direttamente integrate con una macchina munita di ambiente iOS. <\/p>\n\n\n\nOltre all\u2019ambiente, gli altri vantaggi sono il maggior tempo per progredire come tecnologia ed essere raffinata e il maggiore supporto della community che quindi porta ad avere pi\u00f9 esempi e integrazioni gi\u00e0 fatte.<\/p>\n\n\n\n
Detto ci\u00f2, siamo dovuti partire dal presupposto che l’unico modo per rilasciare un\u2019applicazione iOS su AWS utilizzando servizi managed e senza importare strumenti di terze parti, come un\u2019immagine Docker MacOS, fosse utilizzare un’istanza EC2 MAC<\/strong>. <\/p>\n\n\n\nAbbiamo dunque dovuto capire come integrare questa macchina dentro ad una Pipeline, dato che non vi sono integrazioni gi\u00e0 fatte da AWS. La strada che abbiamo ritenuto essere la migliore \u00e8 stata quella di utilizzare una StepFunction<\/strong> per orchestrare le varie operazioni necessarie per costruire e rilasciare l\u2019applicazione.<\/p>\n\n\n\nL’idea era quella di controllare se la singola macchina fosse gi\u00e0 in utilizzo da qualche altro ambiente e, nel caso, attendere che la build fosse finita cos\u00ec da evitare di raddoppiare i tempi di rilascio per entrambi; <\/p>\n\n\n\n
Il dubbio successivo riguardava come comunicare direttamente con la macchina tramite questa StepFunction. <\/p>\n\n\n\n
Confrontando i requisiti con le nostre possibilit\u00e0 siamo giunti ad una conclusione interrogando la macchina tramite SSM con l\u2019API di \u2018SendCommand\u2019.<\/p>\n\n\n\n
I comandi servivano per poter lanciare i vari script .SH necessari per i vari step di predisposizione della macchina e di rilascio dell’applicazione.<\/p>\n\n\n\n
Come abbiamo fatto per la soluzione di AWS, vediamo Pro e Contro anche della nostra:<\/p>\n\n\n\n
PRO<\/h4>\n\n\n\n Personalizzazione<\/strong><\/p>\n\n\n\nUna soluzione costruita da zero, come tutte le cose, ci permette di crearla come pi\u00f9 ci aggrada e con ci\u00f2 che riteniamo davvero utile. In questo caso, ad esempio, siamo stati in grado di aggiungere altri applicativi come IXGuard e mantenere sempre la versione pi\u00f9 aggiornata di XCode cos\u00ec da facilitare anche il lavoro degli sviluppatori e andare in contro alle esigenze del cliente.<\/p>\n\n\n\n
Vantaggi economici<\/strong><\/p>\n\n\n\nIl costo risulta essere pi\u00f9 basso nel confronto singola istanza e singolo CodeBuild, grazie all’utilizzo di molti servizi serverless, come AWS Lambda e AWS Step Function. Mentre il costo dell’EC2 pu\u00f2 essere abbattuto dai Saving Plan.<\/p>\n\n\n\n
CONTRO<\/h4>\n\n\n\n Overhead gestionale<\/strong><\/p>\n\n\n\nSicuramente gestire la logica di integrazione con l’istanza EC2 \u00e8 molto pi\u00f9 complicato rispetto a utilizzare una soluzione Out Of The Box come AWS CodeBuild fornitoci da AWS, ma al contempo offre la possibilit\u00e0 di avere una nostra macchina e una nostra integrazione ci permette di avere un controllo e flessibilit\u00e0 ben maggiori come indicato sopra.<\/p>\n\n\n\n
Singola AZ<\/strong><\/p>\n\n\n\nL’istanza EC2 \u00e8 una singola istanza fisica in una singola AZ e ci\u00f2 va contro i principi dell\u2019alta disponibilit\u00e0; nel caso in cui una AZ dovesse andare fuori servizio la nostra macchina non potrebbe essere pi\u00f9 utilizzata provocando disservizio. <\/p>\n\n\n\n
Gestione degli aggiornamenti<\/strong><\/p>\n\n\n\nUn\u2019altra problematica \u00e8 il caso in cui ci fosse la necessit\u00e0 di eseguire un update, o upgrade del sistema operativo o di un applicativo; si andrebbe certamente incontro a disservizio. Questo perch\u00e9 dopo un aggiornamento di una \u2018Major Version\u2019 qualche funzionalit\u00e0 potrebbe cambiare e portare a degli errori imprevisti, richiedendo dunque del tempo per risolverli, dato che non \u00e8 possibile prevederli prima dell\u2019upgrade.<\/p>\n\n\n\n
Per risolvere la problematica relativa gli aggiornamenti abbiamo trovato molto utile avere una seconda istanza spenta con una AMI preconfigurata e allineata con la macchina di produzione<\/strong>. In questo modo, potr\u00e0 essere utilizzata per testare gli aggiornamenti e poi decidere con consapevolezza come procedere, essendo gli aggiornamenti sempre pianificabili.<\/p>\n\n\n\n\u00c8 anche possibile lasciare l’istanza sempre operativa, ma questo comporta dei costi non trascurabili; dipende quindi da cosa ritenete essere pi\u00f9 importante.<\/p>\n\n\n\n
Conclusioni<\/h2>\n\n\n\n Esiste una soluzione migliore rispetto all’altra? <\/p>\n\n\n\n
Forse…ma non l’abbiamo trovata. La risposta, come sempre, \u00e8 “dipende”: se cercate una soluzione rapida e ben integrata, CodeBuild potrebbe essere la scelta giusta. Se invece avete bisogno di controllo e flessibilit\u00e0, l\u2019istanza EC2 con Step Functions e Lambda potrebbe essere pi\u00f9 adatta. <\/p>\n\n\n\n
Entrambe le soluzioni, sia la nostra che quella di AWS, comunque richiedono la creazione e la gestione degli script<\/strong> necessari per installare i prerequisiti, per poter creare il file .IPA e per poterlo poi rilasciare.<\/p>\n\n\n\nQuesta risulta essere la parte pi\u00f9 complessa, laboriosa e di difficile gestione. <\/p>\n\n\n\n
Se volete qualche consiglio o esempio fatecelo sapere. Sarebbe una perfetta “Parte II” di questo articolo!<\/p>\n\n\n\n
Per il momento \u00e8 tutto.<\/p>\n\n\n\n
Arrivederci al prossimo articolo su Proud2beCloud!<\/p>\n\n\n\n
\n\n\n\nAbout Proud2beCloud<\/h4>\n\n\n\n Proud2beCloud \u00e8 il blog di beSharp<\/a>, APN Premier Consulting Partner italiano esperto nella progettazione, implementazione e gestione di infrastrutture Cloud complesse e servizi AWS avanzati. Prima di essere scrittori, siamo Solutions Architect che, dal 2007, lavorano quotidianamente con i servizi AWS. Siamo innovatori alla costante ricerca della soluzione pi\u00f9 all’avanguardia per noi e per i nostri clienti. Su Proud2beCloud condividiamo regolarmente i nostri migliori spunti con chi come noi, per lavoro o per passione, lavora con il Cloud di AWS. Partecipa alla discussione!<\/p>\n\n\n\n<\/p>\n","protected":false},"excerpt":{"rendered":"
Introduzione Avete mai dovuto creare un\u2019applicazione iOS su Amazon Web Services? Se la risposta \u00e8 no, allora questo articolo fa […]<\/p>\n","protected":false},"author":30,"featured_media":7338,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[477],"tags":[291,711,364],"class_list":["post-7330","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-native-development","tag-aws-codebuild","tag-aws-codebuild-macos-builds-it","tag-ci-cd"],"yoast_head":"\n
Creare App iOS con AWS Codebuild: Pro, Contro e la nostra soluzione alternativa - Proud2beCloud Blog<\/title>\n \n \n \n \n \n \n \n \n \n \n \n\t \n\t \n\t \n \n \n \n \n \n \n\t \n\t \n\t \n