Ricordo un istituto finanziario che cercava di razionalizzare la propria pipeline di sviluppo circa 10 anni fa e di creare quella che oggi chiameremo piattaforma. Hanno notato quanto fossero lenti i tempi di onboarding per i nuovi sviluppatori e quanto potessero essere incoerenti gli usi della tecnologia. Avevano un comitato di architettura, ma era lontano dallo sviluppo quotidiano. La metodologia agile li ha informati che tutto dovrebbe essere automatizzato, quindi hanno adottato questo approccio nella loro pipeline.
Quello che stavano facendo si stava muovendo verso a Ambiente di sviluppo cloudO CDE. C’era una vaga intesa sul fatto che se avessero messo insieme tutti gli strumenti “migliori della categoria”, ciò avrebbe potuto fornire una buona esperienza di onboarding. Ma uno dei problemi era capire come sintetizzare le diverse esperienze di sviluppo all’interno dell’organizzazione e come evitare di perdere competenze che avrebbero potuto fondersi attorno a un ambiente unico. Aveva senso sacrificare la competenza per ottenere la standardizzazione?
Questo post riguarda la comprensione di come la risposta a questa domanda colpisce il tuo team, alla luce di tutte le nuove opzioni CDE. E richiede ancora una riflessione onesta su come opera il tuo team nella tua organizzazione.
L’analogia CDE-WordPress
Non è necessario pensare allo sviluppo per esaminare le esperienze cloud. Come molte altre pubblicazioni online, The New Stack funziona sulla piattaforma WordPress. Quando scrivo un post, c’è una buona probabilità che voglia presentare uno snippet di codice che includa parentesi angolari. Se inserisco semplicemente lo snippet come contenuto, le parentesi angolari potrebbero essere interpretate come un’istruzione o sostituite da Entità HTML che probabilmente conosci fin troppo bene: “<” e “>”. In ogni caso: ho riscontrato un intoppo nel mio ruolo di utente della piattaforma, un problema con il sistema. E ora l’orologio parte.
- La piattaforma, o almeno Google, mi indirizzerà verso una soluzione?
- Chi capisce davvero il problema? Anche la persona che comprende la questione ha accesso alla piattaforma?
- Quanto tempo richiederà la risoluzione?
- Dovrei semplicemente evitare il codice?
In questa situazione, la risposta ha coinvolto l’eccellente team interno che ha riconosciuto il problema e ha dato rapidamente accesso al plugin WordPress appropriato. Il tempo era importante, ma in nessun modo critico. Alla fine l’attenzione è rivolta allo scrittore che si esprime nel modo più accurato possibile. Ma se la situazione diventasse critica, potrei correggere il mio post più tardi.
Ora immagina che il tuo team di sviluppo software si avvicini a una scadenza e si presenti un problema problematico. Il team ha le competenze per isolare il problema? È più importante che gli sviluppatori originali possano esprimersi o che il team mantenga un approccio collaborativo? Rispondere onestamente a queste domande aiuta a capire come entrare negli ambienti online.
Elaborazione su richiesta con CDE
Oggi consideriamo un CDE come un ambiente di sviluppo on-demand fornito con tutti gli strumenti e le dipendenze preconfigurate necessarie per creare e distribuire applicazioni, purché esista il modello per il tipo di applicazione che desideri creare. Normalmente operano all’interno di una fascia di prestazione nota; cioè, hai un’idea di quanta RAM e CPU possono avviare i loro contenitori. Come la maggior parte dei prodotti cloud, potresti essere in grado di accedervi solo tramite il Web. Nel mio ultimo articolo, ho esaminato il popolare ambiente online Replica utilizzando Ghostwriter AI e ho notato quanto fosse facile iniziare.
IL Libro bianco sul CDE Gitpod descrive quattro qualità principali di un CDE: equità, coerenza, estensibilità e disponibilità su richiesta. Chiunque può avviare una sessione con un ambiente di sviluppo e ottenere lo stesso ambiente di chiunque altro. È molto più che semplicemente girare un contenitore e distribuirlo; deve essere disponibile una pipeline completa per creare un’applicazione completa dal codice. Proprio come Google Docs, una sessione è immediatamente disponibile, 24 ore su 24, 7 giorni su 7. La collaborazione è abbastanza naturale.
Self-hosting e standardizzazione
Daytona ha quello che chiama un ambiente di sviluppo standardizzato (SDE), che riguarda in gran parte i CDE self-hosting e la necessità di controllare questi sforzi. Coder.com ha un aspetto leggermente diverso approccio al self-hosting.
Molte grandi organizzazioni hanno creato i propri ambienti cloud, citando la necessità di controllare costi, sicurezza o scalabilità. SDE riconosce la necessità di creare modelli per consentire agli sviluppatori di utilizzare i propri strumenti o accedere alle risorse contenute con l’intelligenza artificiale; per lavorare localmente o online.
Il self-hosting avvicina la flessibilità e il controllo agli utenti interni, ma favorisce chiaramente le organizzazioni con le competenze per collegare tutto.
Ad alcuni sviluppatori piace davvero la configurazione
Ad alcuni ingegneri piace particolarmente lavorare su configurazioni e codice dell’infrastruttura. Se queste abilità esistono nella tua squadra, allora ha senso sfruttarle. Al contrario, molti sviluppatori detestano armeggiare con uno script che non assomiglia al loro codice di sviluppo quotidiano. Più precisamente, potrebbero non aver mai approfondito il funzionamento di sistemi come Ansible o Chef quando erano in voga e potrebbero escogitare soluzioni simili a spaghetti per riparare le piattaforme.
Stai effettuando l’onboarding per la standardizzazione o no?
Il vantaggio più importante di un ambiente in scatola (Software-as-a-Service o SaaS) – come GitHub Codespaces – è che accelera enormemente l’onboarding. La conoscenza del team su quell’ambiente non avrà l’ampiezza che si verifica quando ognuno ha un’esperienza leggermente diversa, a causa del modo in cui l’ha installato. È molto più probabile che qualsiasi documento su come iniziare sia del tutto accurato per ciascun utente. Ma ci sono problemi nel presumere che, poiché voglio un ambiente, ne voglio uno per lo stesso motivo dell’ultima persona che lo voleva.
Un onboarding più eterodosso consente a tutti di entrare rapidamente nell’ambiente, senza dare per scontato che tu sappia esattamente cosa vogliono fare una volta arrivati. Un buon esempio è il dirigente marketing curioso che vuole fare di più che utilizzare le diapositive e desidera eseguire una build attuale. Consentire loro di avviare una build ha senso, ma non se devono prima impostare i tunnel SSH. I vantaggi che possono ottenere aggiornando una risorsa immagine con il logo di un potenziale cliente – qualcosa che non possono fare semplicemente da dietro un browser web – potrebbero essere enormi. D’altro canto, qualcuno che si presenta per valutare rapidamente il progetto potrebbe voler eseguire una serie di build di epoche diverse e potrebbe trovarsi in difficoltà non avendo il pieno controllo degli strumenti a lui familiari.
Codifica per innovazione vs. produzione
Il grande vantaggio dei container marittimi (o container intermodali) è che hanno dimensioni standard. Ciò ha rivoluzionato il controllo dei costi nel trasporto marittimo, poiché i porti per container possono essere costruiti in anticipo con un modello funzionante. Potresti chiederti perché ci sia voluto così tanto tempo (gli anni ’70) perché questi avvenissero. Naturalmente, ci sono stati molti tentativi prima di questo: ciò che in realtà ha standardizzato sono i modelli del commercio internazionale. Allo stesso modo, devi guardare onestamente la tua squadra e capire se la loro scopo è una consegna o un lavoro skunk ispirato.
La sicurezza dei dati non è mai stata il problema che si presume sia. È più una questione di geografia giuridica: dove i dati possono essere conservati. Altrimenti, è improbabile che i dati conservati nel proprio data center interno siano più sicuri di quanto lo siano nel data center di un’azienda pagata esplicitamente per la sicurezza. Ma il termine “sicurezza” può anche significare sicurezza all’interno del proprio sandbox o garantire che gli sviluppatori non abbiano troppo codice sui propri laptop. Per la maggior parte del tempo rimane una questione più politica che letterale.
Inizia con ciò che fa il tuo team
Quindi la conclusione è assicurarti di sapere cosa sta realmente facendo la tua squadra, quindi spingere un po’ a prova di futuro. L’intelligenza artificiale potrebbe essere un vantaggio ora, ma essenziale in seguito. Potresti sapere esattamente quanto grande è il contenitore di cui hai bisogno adesso, ma ciò potrebbe cambiare. Potresti giungere alla conclusione che l’unica cosa che il tuo team dovrebbe condividere è un repository git. Forse alcuni contenitori sotto Docker. Forse un CDE completo o forse qualcosa ospitato autonomamente. In ogni caso, inizia con le basi su come verrebbero risolti i primi conflitti.
