E tuttavia non hai risposto alla domanda: \"Jenkins \u00e8 necessario o no?\"<\/em><\/p>\n<\/p>\n
Jenkins non \u00e8 necessario in nessun caso, in realt\u00e0. Se vogliamo essere seri, strumenti come Jenkins e Gitlab ti offriranno comodit\u00e0. Vedrai se la build \u00e8 andata a buon fine o meno. Possono aiutarti, ma non forniscono pratiche. Possono darti solo un cerchietto \u2013 Ok o non Ok. E questo solo se stai scrivendo test, perch\u00e9 senza test \u00e8 quasi inutile. Quindi \u00e8 necessario perch\u00e9 \u00e8 pi\u00f9 comodo, ma in generale puoi vivere anche senza di esso, non perderai molto. <\/p>\n
<\/p>\n
Cio\u00e8, se hai pratiche, significa che non ti serve?<\/em><\/p>\n<\/p>\n
Esattamente. Ti consiglio il test di Jez Humble. Ho un'opinione ambivalente sull'ultimo punto. Ma in generale, se hai tre cose: ti unisci costantemente, esegui test sui commit nel ramo master, ripari rapidamente la build nel master, allora forse non ti serve altro. <\/p>\n
<\/p>\n
Mentre aspettiamo domande dai partecipanti, ho una domanda. Abbiamo parlato di codice di prodotto. Hai mai utilizzato per il codice infrastrutturale? \u00c8 lo stesso tipo di codice, segue gli stessi principi e ha lo stesso ciclo di vita, oppure ci sono altri cicli di vita e principi? Di solito, quando si parla di Continuous Integration e Development, si dimentica che c'\u00e8 anche il codice infrastrutturale. E ultimamente ce n'\u00e8 sempre di pi\u00f9. Dovremmo applicare tutte queste regole anche l\u00ec?<\/em><\/p>\n<\/p>\n
Non solo dovremmo, sarebbe fantastico, perch\u00e9 in questo modo si semplificherebbe sicuramente la vita. Non appena lavoriamo con codice, non con script bash, ma abbiamo codice normale.<\/p>\n
<\/p>\n
Aspetta, aspetta, uno script bash \u00e8 comunque codice. Non toccare il mio vecchio amore.<\/em> <\/p>\n<\/p>\n
Va bene, non calpester\u00f2 i tuoi ricordi. Ho un'avversione personale nei confronti di bash. Si rompe in modo brutto e spaventoso tutto il tempo. E si rompe spesso in modo imprevedibile, quindi non lo gradisco. Ma va bene, supponiamo che tu abbia codice in bash. Forse davvero non capisco e l\u00ec ci sono framework normali per il testing. Non sono affatto aggiornato. E otteniamo gli stessi vantaggi.<\/p>\n
<\/p>\n
Appena iniziamo a lavorare con l'infrastruttura come se fosse codice, ci troviamo di fronte agli stessi problemi degli sviluppatori. Qualche mese fa, mi sono trovato in una situazione in cui un collega mi ha inviato una pull request di 1.000 righe in bash. E tu rimani bloccato nella revisione per 4 ore. I problemi sono gli stessi. \u00c8 ancora codice. E ancora collaborazione. Rimaniamo bloccati con la pull request e ci impantaniamo con la risoluzione degli stessi conflitti di merge dello stesso bash, per esempio. <\/p>\n
<\/p>\n
Attualmente sto seguendo con molta attenzione questa cosa sul programmazione bella dell'infrastruttura. Ho appena introdotto Pulumi nell'infrastruttura. \u00c8 puro programming. \u00c8 ancora pi\u00f9 carino, perch\u00e9 ho tutte le possibilit\u00e0 del linguaggio di programmazione; quindi ho creato dei toggle carini con gli if in un attimo e tutto va bene. Cio\u00e8, la mia modifica \u00e8 gi\u00e0 nel master. \u00c8 gi\u00e0 visibile a tutti. Altri ingegneri ne sono a conoscenza. Ha gi\u00e0 avuto un certo impatto. Ma si \u00e8 attivata non per tutte le infrastrutture. Si \u00e8 attivata per i miei ambienti di test, per esempio. Quindi, rispondendo di nuovo alla tua domanda, \u00e8 necessario. Ci semplifica la vita come ingegneri che lavorano con il codice. <\/p>\n
<\/p>\n
Se qualcuno ha altre domande?<\/em> <\/p>\n<\/p>\n
Ho una domanda. Voglio continuare la discussione con Oleg. In generale, penso che tu abbia ragione: se un compito richiede un mese, hai un problema di architettura, un problema di analisi, scomposizione, pianificazione, ecc. Ma ho la sensazione che se inizi a vivere secondo il Continuous Integration, inizierai a risolvere i problemi di pianificazione, perch\u00e9 non puoi sfuggire a questa realt\u00e0. <\/p>\n
<\/p>\n
(Oleg) S\u00ec, \u00e8 tutto vero. In termini di lavoro, questa pratica \u00e8 paragonabile a qualsiasi altra pratica seria che cambia la cultura. La cosa pi\u00f9 difficile nel superare questo \u00e8 l'abitudine, soprattutto le cattive abitudini. E se per implementare questa pratica \u00e8 necessaria una seria modifica delle abitudini delle persone intorno a te: sviluppatori, management, production manager, ti aspettano delle sorprese.<\/em> <\/p>\n<\/p>\n
Quali sorprese possono esserci? Diciamo che hai deciso di effettuare integrazioni pi\u00f9 frequentemente. E con le integrazioni hai legato altre cose, ad esempio, artefatti. E nella tua azienda, ad esempio, c'\u00e8 una politica secondo cui ogni artefatto deve essere in qualche modo registrato in un certo sistema di archiviazione degli artefatti. Questo richiede un certo tempo. \u00c8 necessario che qualcuno segni che, come release manager, ha verificato che questo artefatto \u00e8 pronto per essere rilasciato in produzione. Se questo richiede 5-10-15 minuti, ma tu effettui un rilascio una volta alla settimana, dedicare mezz'ora a questo ogni settimana non \u00e8 un grande prezzo.<\/em> <\/p>\n<\/p>\n
Se fai Continuous Integration 10 volte al giorno, devi moltiplicare 10 per 30 minuti. E questo supera la quantit\u00e0 di tempo lavorativo di quel release manager. Si stanca semplicemente di farlo. Ci sono costi costanti per alcune pratiche. E basta.<\/em> <\/p>\n<\/p>\n
E devi o annullare questa regola, in modo da non dover pi\u00f9 occuparti di queste cose, cio\u00e8 non assegni manualmente il grado di conformit\u00e0 di qualcosa a qualcosa. Ti affidi totalmente a una serie di test automatizzati di prontezza.<\/em> <\/p>\n<\/p>\n
E se hai bisogno di un'approvazione da qualcuno affinch\u00e9 il principale firmi, e non entri in produzione senza che Vasya abbia detto che va bene, ecc. \u2013 tutta questa burocrazia ostacola le pratiche. Perch\u00e9 se ci sono attivit\u00e0 collegate come un onere, tutto aumenta di 100 volte. Pertanto, il cambiamento sar\u00e0 spesso percepito con meno entusiasmo. Perch\u00e9 \u00e8 difficile correggere le abitudini delle persone.<\/em> <\/p>\n<\/p>\n
Quando una persona svolge un lavoro abituale, lo fa praticamente senza pensarci. Il suo carico cognitivo \u00e8 pari a zero. Esegue semplicemente il compito, la sua mente ha gi\u00e0 un checklist, lo ha fatto mille volte. E non appena arrivi e gli dici: \u201cAnnulliamo questa pratica e da luned\u00ec ne implementiamo una nuova\u201d, per lui diventa un notevole carico cognitivo. E ci\u00f2 si verifica immediatamente per tutti.<\/em> <\/p>\n<\/p>\n
Pertanto, la cosa pi\u00f9 semplice, anche se non tutti possono permettersi questo lusso, \u00e8 proprio ci\u00f2 che faccio sempre. Quando inizia un nuovo progetto, di solito vengono subito inglobate tutte le pratiche non testate. Finch\u00e9 il progetto \u00e8 giovane, non rischiamo molto. Non c'\u00e8 ancora produzione, non c'\u00e8 nulla da distruggere. Quindi possiamo utilizzarlo come allenamento. Questo approccio funziona. Ma non tutte le aziende hanno la possibilit\u00e0 di avviare progetti come questi frequentemente. Anche se \u00e8 un po' strano, perch\u00e9 ora si parla di trasformazione digitale, tutti devono avviare esperimenti per stare al passo con i concorrenti.<\/em> <\/p>\n<\/p>\n
Qui ti scontri con il fatto che devi avere prima una comprensione di cosa devi fare. Il mondo non \u00e8 perfetto, n\u00e9 la produzione \u00e8 perfetta. <\/p>\n
<\/p>\n
S\u00ec, queste cose sono collegate.<\/em><\/p>\n<\/p>\n
Anche le aziende non hanno sempre chiaro che devono andare in una certa direzione. <\/p>\n
<\/p>\n
Ci sono situazioni in cui nessun cambiamento \u00e8 possibile. Questa \u00e8 una situazione in cui il team \u00e8 sotto una pressione maggiore. Il team \u00e8 gi\u00e0 abbastanza provato. Non ha tempo di riserva per esperimenti. Lavorano tutto il giorno per sviluppare funzionalit\u00e0. E la direzione richiede sempre pi\u00f9 funzionalit\u00e0. In una tale situazione, nessun cambiamento \u00e8 possibile. Allo staff pu\u00f2 solo essere detto che domani faremo come ieri, dobbiamo solo fare qualche funzionalit\u00e0 in pi\u00f9. Nessuna transizione a pratiche diverse \u00e8 possibile in questo senso. Questa \u00e8 una situazione classica in cui non c'\u00e8 tempo per affilare l'ascia, bisogna abbattere gli alberi, quindi si abbattono con un'ascia smussata. Non ci sono consigli facili qui.<\/em> <\/p>\n<\/p>\n
(Dmitrij) Legger\u00f2 un chiarimento dalla chat: \u00abMa \u00e8 necessario avere una vasta copertura di test a diversi livelli. Quanto tempo \u00e8 dedicato ai test? \u00c8 un po' costoso, richiede molto tempo\u00bb.<\/em><\/p>\n<\/p>\n
(Oleg) Questo \u00e8 un malinteso classico. Ci devono essere abbastanza test affinch\u00e9 voi stessi siate sicuri. L'Integrazione Continua non \u00e8 una cosa in cui inizi prima con il 100% di test e solo poi inizi a praticarla. L'Integrazione Continua riduce il carico cognitivo su di voi, dato che ogni cambiamento che vedete \u00e8 cos\u00ec ovvio che capite se romper\u00e0 qualcosa o meno, anche senza test. Potete testarlo mentalmente rapidamente, perch\u00e9 sono piccole modifiche. Anche se avete solo tester manuali, \u00e8 pi\u00f9 semplice per loro. Avete rilasciato e detto:<\/em><\/p>\n<\/p>\n
Qui hai, ovviamente, esagerato. <\/p>\n
<\/p>\n
(Dmitry) Qui non sono d'accordo. Esiste una pratica - lo sviluppo tramite test - che vi salver\u00e0 proprio da questo.<\/em> <\/p>\n<\/p>\n
(Oleg) Ecco, non ci ero ancora arrivato. La prima illusione \u00e8 che bisogna scrivere esattamente il 100% dei test o che non si debba affatto praticare l'Integrazione Continua. Non \u00e8 vero. Sono due pratiche parallele. E non dipendono direttamente l'una dall'altra. La vostra copertura dei test deve essere ottimale. Ottimale significa che voi stessi siete sicuri che la qualit\u00e0 del master, rimasta dopo il commit, vi permetta di premere il pulsante \"Distribuisci\" con sicurezza venerd\u00ec sera, mentre siete ubriachi. Come ci riuscite? Attraverso revisioni, copertura e un buon monitoraggio.<\/em> <\/p>\n<\/p>\n
Un buon monitoraggio \u00e8 indistinguibile dai test. Se eseguite i test una sola volta su pre-produzione, controllano solo una volta tutti i vostri scenari utente e poi basta. Se li eseguite in un ciclo infinito, allora \u00e8 il vostro sistema di monitoraggio esteso che testando tutto in continuazione - \u00e8 caduto o non \u00e8 caduto. In questo caso, la differenza sta solo nell'unicit\u00e0 o molteplicit\u00e0. Un insieme molto buono di test, ...lanciato indefinitamente, \u00e8 monitoraggio. E un corretto monitoraggio deve essere proprio cos\u00ec.<\/em> <\/p>\n<\/p>\n
E quindi, come raggiungerete esattamente lo stato in cui venerd\u00ec sera vi distribuite e andate a casa, \u00e8 un'altra questione. Forse siete solo un temerario.<\/em> <\/p>\n<\/p>\n
Torniamo un po' indietro al Continuous Integration. Siamo scivolati in un'altra pratica complessa. <\/p>\n
<\/p>\n
E la seconda illusione \u00e8 che l'MVP, si dice, debba essere fatto rapidamente, quindi i test non servono affatto. Non \u00e8 del tutto cos\u00ec. La questione \u00e8 che quando scrivi una user story in un MVP, puoi svilupparla o senza scrupoli, cio\u00e8 hai sentito che c'\u00e8 una certa user story e subito inizi a codificare, oppure lavorare secondo TDD. E con TDD, come dimostra la pratica, non ci si impiega di pi\u00f9, cio\u00e8 i test sono un effetto collaterale. La pratica del TDD non riguarda solo il testare. Nonostante si chiami Test Driven Development, qui si parla in realt\u00e0 di architettura. \u00c8 un approccio su come scrivere esattamente ci\u00f2 di cui hai bisogno e non scrivere ci\u00f2 che non serve. Questa pratica \u00e8 focalizzata sulla prossima iterazione del tuo sviluppo in termini di creazione dell'architettura dell'applicazione.<\/em> <\/p>\n<\/p>\n
Perci\u00f2 non \u00e8 cos\u00ec semplice liberarsi da queste illusioni. MVP e test non si escludono a vicenda. Anzi, \u00e8 piuttosto l'opposto: se sviluppi l'MVP seguendo la pratica TDD, lo farai meglio e pi\u00f9 velocemente rispetto a farlo senza alcuna pratica e senza una logica.<\/em><\/p>\n<\/p>\n
\u00c8 un pensiero molto non ovvio e complesso. Quando senti dire che adesso scriver\u00f2 anche i test e nel frattempo far\u00f2 qualcosa di pi\u00f9 velocemente, suona assolutamente inadeguato. <\/p>\n
<\/p>\n
(Dmitrij) Qui molte persone, quando parlano di MVP, si \u00e8 pigri a scrivere qualcosa di normale. E queste sono comunque due cose diverse. Non bisogna trasformare l'MVP in una cosa brutta che non funziona.<\/em> <\/p>\n<\/p>\n
S\u00ec, hai ragione.<\/p>\n
<\/p>\n
E poi, all'improvviso, l'MVP in produzione.<\/em><\/p>\n<\/p>\n
Per sempre. <\/p>\n
<\/p>\n
E TDD suona molto insolito quando senti che scrivi test e sembri fare pi\u00f9 lavoro. Questo suona molto strano, ma in realt\u00e0 ci si riesce pi\u00f9 velocemente e meglio. Quando scrivi un test, gi\u00e0 nella tua testa stai pensando molto a quale codice e come sar\u00e0 chiamato, e anche quale comportamento ci aspettiamo da esso. Non stai solo dicendo che ho scritto una certa funzione e che fa qualcosa. Prima hai pensato che avesse determinate condizioni, che sarebbe stata chiamata in un certo modo. Copri questo con i test e da questo capisci come appariranno le interfacce all'interno del tuo codice. Questo influisce notevolmente sull'architettura. Il tuo codice diventa automaticamente pi\u00f9 modulare, perch\u00e9 prima cerchi di capire come lo testerai e solo dopo lo scrivi. <\/p>\n
<\/p>\n
Con TDD \u00e8 successo che a un certo punto ho assunto un mentore per Ruby, quando ero ancora un programmatore Ruby. E lui dice: \u00abFacciamo che tu farai TDD\u00bb. E io penso: \u00abCavolo, devo scrivere ancora qualcosa\u00bb. Cos\u00ec ci siamo messi d'accordo che avrei scritto tutto il codice lavorativo in Python seguendo il TDD per due settimane. Dopo due settimane ho capito che non volevo tornare indietro. Provando ad applicarlo ovunque per due settimane, ti rendi conto di quanto sia diventato pi\u00f9 semplice anche solo pensare. Ma non \u00e8 ovvio, quindi consiglio a tutti che, se avete l'impressione che il TDD sia difficile, lungo e superfluo, provate a seguirlo per sole due settimane. A me sono bastate due settimane per rendermene conto.<\/p>\n
<\/p>\n
(Dmitrij) Possiamo approfondire questo concetto dal punto di vista dell'utilizzo dell'infrastruttura. Prima di avviare qualcosa di nuovo, eseguiamo il monitoraggio, e poi lanciamo. In questo caso il monitoraggio diventa un vero e proprio test. E c'\u00e8 uno sviluppo attraverso il monitoraggio. Ma quasi tutti dicono che \u00e8 lungo, che \u00e8 noioso, ho fatto una bozza temporanea. Se abbiamo fatto un buon monitoraggio, comprendiamo lo stato del sistema CI. E nel sistema CI ci sono molti monitoraggi. Comprendiamo lo stato del sistema, capiamo cosa accade al suo interno. E durante lo sviluppo ci assicuriamo di portare il sistema allo stato desiderato.<\/em> <\/p>\n<\/p>\n
Queste pratiche sono conosciute da tempo. Ne parlavamo circa 4 anni fa. Ma in 4 anni praticamente nulla \u00e8 cambiato.<\/em> <\/p>\n<\/p>\n
Ma su questa nota propongo di concludere la discussione ufficiale.<\/em><\/p>\n<\/p>\n
Video (inserito come elemento multimediale, ma per qualche motivo non funziona):<\/p>\n
\nhttps:\/\/youtu.be\/zZ3qXVN3Oic<\/a><\/noindex> habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041e\u0431\u0441\u0443\u0434\u0438\u043c \u043f\u043e\u0447\u0435\u043c\u0443 CI-\u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b \u0438 CI \u2013 \u044d\u0442\u043e \u0441\u043e\u0432\u0441\u0435\u043c \u043f\u0440\u043e \u0440\u0430\u0437\u043d\u043e\u0435. \u041a\u0430\u043a\u0443\u044e \u0431\u043e\u043b\u044c CI \u043f\u0440\u0438\u0437\u0432\u0430\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c, \u043e\u0442\u043a\u0443\u0434\u0430 \u0432\u043e\u0437\u043d\u0438\u043a\u043b\u0430 \u0438\u0434\u0435\u044f, \u043a\u0430\u043a\u0438\u0435 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u0438\u044f \u0447\u0442\u043e \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u043a\u0430\u043a \u043f\u043e\u043d\u044f\u0442\u044c \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 \u0435\u0441\u0442\u044c \u0438\u043c\u0435\u043d\u043d\u043e \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0430, \u0430 \u043d\u0435 \u043f\u0440\u043e\u0441\u0442\u043e \u0443\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u043d\u044b\u0439 Jenkins. \u041c\u044b\u0441\u043b\u044c \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0434\u043e\u043a\u043b\u0430\u0434 \u043f\u0440\u043e Continuous Integration \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u0435\u0449\u0435 \u0433\u043e\u0434 \u043d\u0430\u0437\u0430\u0434, \u043a\u043e\u0433\u0434\u0430 \u044f \u0445\u043e\u0434\u0438\u043b \u043f\u043e \u0441\u043e\u0431\u0435\u0441\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u044f\u043c \u0438\u0441\u043a\u0430\u043b \u0440\u0430\u0431\u043e\u0442\u0443. \u041f\u043e\u043e\u0431\u0449\u0430\u043b\u0441\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":93886,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-93885","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Continuous](\"\/wp-content\/uploads\/2020\/09\/ed8a32ae63b8dccfc8b4893ab27f1527.jpg\")
<\/p>\n