E comunque non hai risposto alla domanda: \u00abJenkins \u00e8 necessario o non \u00e8 necessario?\u00bb<\/em><\/p>\n<\/p>\n
Jenkins non \u00e8 realmente necessario in alcun caso. Seriamente, strumenti come Jenkins e GitLab vi offriranno comodit\u00e0. Potete vedere se la build \u00e8 andata a buon fine o meno. Possono esservi utili, ma non vi forniranno vere pratiche. Possono solo darvi un pallino \u2013 Ok o Non Ok. E questo, se scrivete ancora dei test, perch\u00e9 se non ci sono test, \u00e8 quasi senza senso. Quindi \u00e8 utile, perch\u00e9 \u00e8 pi\u00f9 comodo, ma in generale si pu\u00f2 anche vivere senza, non perderete molto. <\/p>\n
<\/p>\n
Cio\u00e8, se avete pratiche, significa che non vi serve?<\/em><\/p>\n<\/p>\n
Esatto. Raccomando il test di Jez Humble. Ho un atteggiamento ambivalente riguardo all'ultimo punto. Ma in generale, se avete queste tre cose, vi mergeate costantemente, eseguite test sui commit nel master e riparate rapidamente la build nel master, allora forse non avete bisogno di altro. <\/p>\n
<\/p>\n
Mentre aspettiamo le domande dei partecipanti, ho una domanda. Abbiamo appena parlato di codice di prodotto. Ma hai utilizzato il codice infrastrutturale? \u00c8 lo stesso tipo di codice, ha gli stessi principi e lo stesso ciclo di vita, oppure ci sono cicli di vita e principi diversi? Di solito, quando si parla di Continuous Integration e Development, si dimentica che c'\u00e8 anche il codice infrastrutturale. E ultimamente, sta diventando sempre pi\u00f9 rilevante. Dobbiamo quindi applicare tutte queste regole anche a quello?<\/em><\/p>\n<\/p>\n
Non \u00e8 tanto che dobbiamo, sarebbe fantastico, perch\u00e9 semplificherebbe sicuramente le cose. Una volta che lavoriamo con il codice, non con script bash, ma con un codice solido.<\/p>\n
<\/p>\n
Aspetta un attimo, lo script bash \u00e8 anche questo un codice. Non toccare il mio vecchio amore.<\/em> <\/p>\n<\/p>\n
Va bene, non calpester\u00f2 i tuoi ricordi. Io ho una certa avversione per bash. Si rompe in modo brutto e orrendo continuamente. E si guasta spesso in modo imprevedibile, per questo non lo amo molto. Ma va bene, supponiamo che tu abbia codice in bash. Forse non ne capisco abbastanza e ci sono dei buoni framework per il testing. Non sono aggiornato. E otteniamo gli stessi vantaggi.<\/p>\n
<\/p>\n
Quando trattiamo l'infrastruttura come 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 ti fermi a fare la revisione per 4 ore. I problemi sono gli stessi. \u00c8 sempre codice. E sempre collaborazione. Ci troviamo bloccati con la pull request e incontriamo gli stessi conflitti di merge dello stesso bash, per esempio. <\/p>\n
<\/p>\n
Attualmente sto monitorando molto attivamente tutto questo per massimizzare la bellezza della programmazione dell'infrastruttura. Ho appena integrato Pulumi nella mia infrastruttura. \u00c8 programmazione pura. \u00c8 ancora pi\u00f9 affascinante perch\u00e9 ho accesso a tutte le funzionalit\u00e0 del linguaggio di programmazione, cio\u00e8 ho creato toggle belli nello stesso modo con le istruzioni if. Pertanto, la mia modifica \u00e8 gi\u00e0 nel master. Tutti la vedono. Gli altri ingegneri ne sono a conoscenza. Ha gi\u00e0 avuto qualche impatto. Tuttavia, non \u00e8 stato attivato per tutte le infrastrutture. \u00c8 attivo solo per i miei ambienti di test, per esempio. Quindi, rispondendo di nuovo alla tua domanda, \u00e8 necessario. Ci semplifica sicuramente la vita come ingegneri che lavorano con il codice. <\/p>\n
<\/p>\n
Ci sono altre domande?<\/em> <\/p>\n<\/p>\n
Ho una domanda. Voglio continuare la discussione con Oleg. In generale, penso che tu abbia ragione nel dire che se un compito richiede un mese, hai un problema con l'architettura, con l'analisi, la decomposizione, la pianificazione, ecc. Tuttavia, ho la sensazione che se inizi a vivere secondo il Continuous Integration, comincerai a risolvere i problemi di pianificazione, perch\u00e9 non potrai evitarli. <\/p>\n
<\/p>\n
(Oleg) S\u00ec, \u00e8 tutto corretto. In termini di lavoro, questa pratica \u00e8 paragonabile a qualsiasi altra seria pratica che modifica la cultura. La parte pi\u00f9 difficile da superare sono le abitudini, specialmente quelle sbagliate. E se per implementare questa pratica \u00e8 necessario un cambiamento significativo nelle abitudini degli altri: sviluppatori, management, responsabile della produzione, allora ti aspettano delle sorprese.<\/em> <\/p>\n<\/p>\n
Quali sorprese potrebbero esserci? Supponiamo che tu abbia deciso di effettuare integrazioni pi\u00f9 frequentemente. E queste integrazioni sono legate ad altre cose, ad esempio, artefatti. E nella tua azienda, ad esempio, esiste una politica secondo cui ogni artefatto deve essere in qualche modo registrato in un sistema di archiviazione degli artefatti. E questo richiede un certo tempo. La persona deve contrassegnare che, come release manager, ha testato questo artefatto per la sua prontezza per il deployment in produzione. Se questo richiede 5-10-15 minuti, ma effettui il deployment una volta alla settimana, allora investire mezz'ora una volta a settimana \u00e8 un piccolo dazio.<\/em> <\/p>\n<\/p>\n
Se stai facendo Continuous Integration 10 volte al giorno, allora devi moltiplicare 10 per 30 minuti. E questo supera il tempo lavorativo di quel release manager. Si stanca semplicemente a farlo. Ci sono costi fissi per alcune pratiche. E basta.<\/em> <\/p>\n<\/p>\n
E devi o annullare questa regola, cos\u00ec non ti occupi pi\u00f9 di queste cose illogiche, cio\u00e8 non assegni manualmente il livello di conformit\u00e0 di qualcosa a qualcos'altro. Ti affidi completamente a un insieme automatizzato di test di prontezza.<\/em> <\/p>\n<\/p>\n
E se hai bisogno di un'approvazione per far firmare il principale, e non entri in produzione senza che qualcuno ti dica che va bene, tutto questo ostacola le pratiche. Perch\u00e9 se ci sono attivit\u00e0 legate a tasse, tutto si amplifica di cento volte. Quindi il cambiamento non sar\u00e0 spesso accolto con gioia da tutti. \u00c8 difficile cambiare 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. Lavora seguendo un modello gi\u00e0 pronto, ha una checklist nella mente, l'ha fatto mille volte. E non appena arrivi e gli dici: 'Annulliamo questa pratica e da luned\u00ec implementiamo una nuova', per lui diventa un pesante carico cognitivo. E questo colpisce subito tutti.<\/em> <\/p>\n<\/p>\n
Quindi la cosa pi\u00f9 semplice, anzi, non tutti possono permettersi questo lusso, ma io faccio sempre esattamente cos\u00ec, ed ecco perch\u00e9. Quando inizia un nuovo progetto, generalmente si inseriscono immediatamente in questo progetto tutte le pratiche non testate. Finch\u00e9 il progetto \u00e8 giovane, non rischiamo molto. Non c'\u00e8 ancora un ambiente di produzione, quindi non c'\u00e8 nulla da rovinare. Pertanto, pu\u00f2 essere usato come allenamento. Questo approccio funziona. Ma non tutte le aziende hanno la possibilit\u00e0 di avviare progetti del genere frequentemente. Anche se \u00e8 un po' strano, perch\u00e9 adesso siamo in una continua trasformazione digitale e tutte devono avviare esperimenti per tenere il passo con i concorrenti.<\/em> <\/p>\n<\/p>\n
Qui ti trovi di fronte al fatto che devi prima avere una comprensione di ci\u00f2 che devi fare. Il mondo non \u00e8 perfetto, nemmeno l'ambiente di produzione \u00e8 perfetto. <\/p>\n
<\/p>\n
S\u00ec, queste cose sono collegate.<\/em><\/p>\n<\/p>\n
Le aziende non hanno sempre chiara l'idea che debbano andare da qualche parte. <\/p>\n
<\/p>\n
Esiste una situazione in cui non \u00e8 possibile apportare alcuna modifica. \u00c8 una situazione in cui la pressione sul team \u00e8 maggiore. Il team \u00e8 gi\u00e0 piuttosto bruciato. Non ha alcun margine di tempo per esperimenti. Lavorano dalla mattina alla sera su nuove funzionalit\u00e0. E il management sembra non essere mai soddisfatto delle funzionalit\u00e0. Serve sempre di pi\u00f9. In una tale situazione, non \u00e8 possibile effettuare alcun cambiamento. Al team possono solo dire di continuare a lavorare come ieri, ma con un numero leggermente maggiore di funzionalit\u00e0. Non \u00e8 possibile passare a pratiche diverse in questo senso. \u00c8 una situazione classica in cui non c'\u00e8 tempo per affilare l'ascia, bisogna abbattere gli alberi, di conseguenza si abbattono con un'ascia smussata. Qui non ci sono consigli facili.<\/em> <\/p>\n<\/p>\n
(Dmitriy) Legger\u00f2 un chiarimento dal chat: \u00abMa \u00e8 necessario avere una buona copertura di test a diversi livelli. Quanto tempo viene dedicato ai test? \u00c8 piuttosto costoso e richiede molto tempo\u00bb.<\/em><\/p>\n<\/p>\n
(Oleg) \u00c8 un comune errore. Devono esserci abbastanza test affinch\u00e9 tu stesso sia sicuro. L'integrazione continua non \u00e8 qualcosa dove prima fai il 100% dei test e poi inizi a mettere in pratica. L'integrazione continua riduce il tuo carico cognitivo poich\u00e9 ogni cambiamento che vedi \u00e8 talmente ovvio che capisci se romper\u00e0 qualcosa o meno, anche senza test. Puoi testarlo rapidamente nella tua testa perch\u00e9 le modifiche sono piccole. Anche se hai solo tester manuali, per loro \u00e8 pi\u00f9 semplice. Hai fatto il deployment e hai detto: \u00abGuarda, non si \u00e8 rotto niente?\u00bb. Loro controllano e dicono: \u00abNo, non si \u00e8 rotto niente\u00bb. Perch\u00e9 il tester sa dove guardare. Hai un commit legato a un singolo frammento di codice. E questo esplode in un comportamento specifico.<\/em><\/p>\n<\/p>\n
Qui hai, ovviamente, un po' esagerato. <\/p>\n
<\/p>\n
(Dmitry) Su questo non sono d'accordo. Esiste una pratica \u2013 lo sviluppo attraverso il testing, che ti salver\u00e0 proprio da questo.<\/em> <\/p>\n<\/p>\n
(Oleg) Non ci sono ancora arrivato. La prima illusione \u00e8 che bisogna scrivere il 100% dei test o non occuparsi affatto dell'Integrazione Continua. Non \u00e8 vero. Sono due pratiche parallele e non dipendono direttamente l'una dall'altra. La copertura dei test dovrebbe essere ottimale. Ottimale significa che siete certi che la qualit\u00e0 del master, rimasta dopo il vostro commit, vi permetta di cliccare con fiducia sul pulsante 'Deploy' venerd\u00ec sera, anche se siete un po' brilli. Come si ottiene tutto ci\u00f2? Attraverso le recensioni, la copertura, e un buon monitoraggio.<\/em> <\/p>\n<\/p>\n
Un buon monitoraggio \u00e8 indistinguibile dai test. Se eseguite i test una sola volta in pre-prod, essi controllano tutti i vostri casi d'uso una sola volta e basta. Ma se li eseguite in un ciclo infinito, allora questo diventa il vostro sistema di monitoraggio attivo che testa continuamente \u2013 se \u00e8 andato gi\u00f9 o meno. In questo caso, la differenza sta solo nella singolarit\u00e0 o molteplicit\u00e0. Un insieme di test molto buono ..., eseguito all'infinito, \u00e8 monitoraggio. E il monitoraggio corretto dovrebbe essere proprio cos\u00ec.<\/em> <\/p>\n<\/p>\n
E quindi, come esattamente raggiungerai questo stato, quando venerd\u00ec sera ti deployi e vai a casa, \u00e8 un'altra questione. Forse sei semplicemente un audace trasgressore.<\/em> <\/p>\n<\/p>\n
Torniamo un attimo indietro all'Integrazione Continua. Ci siamo allontanati verso un'altra pratica complicata. <\/p>\n
<\/p>\n
E la seconda illusione \u00e8 che il MVP, dicono, deve essere fatto in fretta, quindi non servono affatto test. Non \u00e8 proprio cos\u00ec. Il fatto \u00e8 che quando scrivi una user story per il MVP, puoi svilupparla in modo casuale, cio\u00e8 ascoltare che c'\u00e8 una user story e correre subito a codificarla, oppure lavorare secondo il TDD. E con il TDD, come dimostra la pratica, non ci si impiega di pi\u00f9, quindi i test sono un effetto collaterale. La pratica del TDD non riguarda il testare. Nonostante si chiami Sviluppo Guidato dai Test, qui non si parla affatto di test. \u00c8 piuttosto un approccio architettonico. \u00c8 un metodo per scrivere precisamente ci\u00f2 di cui hai bisogno e non scrivere ci\u00f2 che non ti serve. Questa pratica si concentra sulla prossima iterazione del tuo pensiero in termini di creazione dell'architettura dell'applicazione.<\/em> <\/p>\n<\/p>\n
Quindi non \u00e8 cos\u00ec facile liberarsi di queste illusioni. MVP e i test non si escludono a vicenda. Anzi, piuttosto il contrario: se realizzi un MVP seguendo la pratica TDD, lo farai meglio e pi\u00f9 velocemente che farlo senza alcuna pratica, e a casaccio.<\/em><\/p>\n<\/p>\n
\u00c8 un pensiero molto sottile e complesso. Quando senti dire che ora scriver\u00f2 pi\u00f9 test e nello stesso tempo far\u00f2 qualcosa pi\u00f9 velocemente, sembra assolutamente inadeguato. <\/p>\n
<\/p>\n
(Dmitrij) Qui molti, quando parlano di MVP, sono semplicemente troppo pigri per scrivere qualcosa di decente. E queste sono comunque cose diverse. Non bisogna trasformare l'MVP in una cosa brutta che non funziona.<\/em> <\/p>\n<\/p>\n
S\u00ec-s\u00ec, hai ragione.<\/p>\n
<\/p>\n
E poi, improvvisamente, MVP in prod.<\/em><\/p>\n<\/p>\n
Per sempre. <\/p>\n
<\/p>\n
Il TDD pu\u00f2 sembrare insolito quando ascolti che stai scrivendo test e apparentemente stai facendo pi\u00f9 lavoro. Sembra strano, ma in realt\u00e0 consente di ottenere risultati pi\u00f9 rapidi e ordinati. Quando scrivi un test, nella tua mente stai gi\u00e0 pensando molto su quale codice e come verr\u00e0 chiamato, nonch\u00e9 quale comportamento ci aspettiamo da esso. Non stai solo dicendo che hai scritto una funzione e che fa qualcosa. Prima pensi che ha tali condizioni e che verr\u00e0 chiamata in un certo modo. Copri tutto questo con i test e di conseguenza comprendi come appariranno le interfacce all'interno del tuo codice. Questo influisce notevolmente sull'architettura. Il tuo codice diventa automaticamente pi\u00f9 modulare, perch\u00e9 cerchi prima di capire come lo testerai, e solo dopo lo scrivi. <\/p>\n
<\/p>\n
Con TDD ho avuto un'esperienza in cui, a un certo punto, ho assunto un mentore per Ruby, mentre ero ancora un programmatore Ruby. E lui dice: \u00abFacciamo che tu faccia tutto con TDD\u00bb. E io pensavo: \u00abCavolo, adesso devo scrivere qualcosa di aggiuntivo\u00bb. Cos\u00ec abbiamo concordato che per due settimane scriverei tutto il codice funzionale in Python seguendo TDD. Dopo due settimane ho capito che non volevo tornare indietro. Dopo aver cercato di applicarlo ovunque per due settimane, ho realizzato quanto fosse pi\u00f9 semplice anche solo pensare. Ma non \u00e8 ovvio, quindi consiglio a tutti che, se avete la sensazione che TDD sia complicato, lungo e superfluo, provate a seguirlo per sole due settimane. A me sono bastate due per capirlo.<\/p>\n
<\/p>\n
(Dmitry) Possiamo sviluppare questo concetto dal punto di vista dell'operativit\u00e0 dell'infrastruttura. Prima di lanciare qualcosa di nuovo, effettuamo un monitoraggio, per poi avviarlo. In questo caso, il monitoraggio diventa un test normale. E c'\u00e8 uno sviluppo attraverso il monitoraggio. Ma quasi tutti dicono che \u00e8 lungo, mi scoccia, ho fatto un bozzetto temporaneo. Se facciamo un monitoraggio corretto, capiamo lo stato del sistema CI. E nel sistema CI c'\u00e8 molto monitoraggio. Comprendiamo lo stato del sistema, capiamo cosa c'\u00e8 all'interno. E durante lo sviluppo, stiamo proprio creando un sistema che raggiunga lo stato desiderato.<\/em> <\/p>\n<\/p>\n
Queste pratiche sono conosciute da tempo. Ne abbiamo parlato circa 4 anni fa. Ma in 4 anni praticamente non \u00e8 cambiato nulla.<\/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 chiss\u00e0 per quale 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