IT knowledge base
CTRL+F per cercare la tua parola chiave

Come creiamo DevOps con un team di 125 sviluppatori

Ciao a tutti.
Mi chiamo Alexander Chernikov , sono il capo dello sviluppo nella divisione Digital Corporate Bank di Sberbank e Sbertech.
Oggi ti parlerò di DevOps presso Sberbank Business Online (SBBOL), che abbiamo creato in un team piuttosto ampio (125 sviluppatori) con una revisione ampia (75 PR al giorno). Ora il processo di debug CD (CI) per le richieste pull (di seguito PR) è parte integrante del lavoro e il nostro orgoglio.

Allora cosa abbiamo fatto:
  1. Abbiamo scritto un plugin speciale per Bitbucket - "Mega Plugin"
  2. Gli ho insegnato a interagire con Jenkins
  3. Avvitato il cosiddetto PrCheck (assemblaggio, test del selenio, linters)
Processo in foto

Ora, più in dettaglio, come è iniziato tutto. Ti dirò sull'esempio di un repository dell'interfaccia utente e se ci sono funzionalità interessanti in altri repository, lo scriverò separatamente.

Che succede con lo sviluppo, amico?

C'era una volta, il nostro sviluppo si interrompeva costantemente a causa di alcuni piccoli errori che venivano visualizzati nella revisione del codice. Questi erano errori di runtime JS, errori di compilazione dattiloscritti, errori di stile globali nell'applicazione (quando l'intera pagina "si separava"), ecc. Nella chat, si sentivano costantemente domande familiari: "Lo sviluppo non è rotto? Posso aggiornare? "," Chi altro non svilupperà? O sono l'unico? "E altri. Poi c'era un team di 10 persone. E all'orizzonte, iniziarono a profilarsi piani per crescere fino a 10-15 team Scrum di 9-10 persone. I nostri superAdmin ed esperti (revisori) erano tristi.
Abbiamo pensato di risolvere il problema della stabilità tramite un hook pre-push git, ma anche questo approccio non ha funzionato per due motivi:
  1. la stabilità non può esistere dove c'è un fattore umano;
  2. È stato crudele far aspettare a tutti gli sviluppatori una build completa del progetto, linters e altri controlli prima di spingere (non c'erano ancora test di Selenium). Inoltre, è un grande tempo di inattività.

Abbiamo iniziato a pensare alla barriera nella fase delle pubbliche relazioni.

Operazione "Jenkins impossibile"

Nelle prime implementazioni, l'inizio del lavoro è stato fatto da questo plugin . quelli. ogni 15 minuti (cron) ha bypassato il PR con nuovi commenti prova questo per favore o nuovi PR, e ha appena iniziato il lavoro. Dopo l'assemblaggio, abbiamo scritto un commento in PR (successo/fallimento) in uno script di shell. Gli esperti hanno guardato il codice, hanno messo le loro approvazioni (non giudicare rigorosamente per gli anglicismi, non sono riuscito a trovare un buon sinonimo).
MA solo pochi eletti potrebbero iniettare il codice, modalità dio. Di solito era una persona per repository che doveva assicurarsi che la build avesse successo, trovare "BUILD SUCCESS", contare il numero di approvazioni e solo allora fare clic sul pulsante Unisci. E posso dirti, per esperienza, che moralmente è molto difficile. Sembra che le approvazioni ci siano, e le "verifiche" siano passate, ma tu ci versi lo stesso, e sei anche responsabile. Nessuno di noi potrebbe sopportarlo per più di tre settimane. I turni sono iniziati :) E dal punto di vista del processo, era ancora un collo di bottiglia, perché anche dopo che tutti i requisiti erano stati soddisfatti, il team doveva trovare qualcuno che premesse il pulsante. Di conseguenza, da 1 ora a un'intera giornata, e talvolta per settimane, le squadre non sono riuscite a trovare questo "prescelto", rannicchiato nell'angolo del capo sviluppatore.
Vale la pena ricordare che Bitbucket ha un'opzione standard per visualizzare lo stato della build . E anche unisci lista di controllo : il numero minimo di approvazioni, almeno una build di successo, tutti i commenti sono consentiti (segni di spunta), ecc. Ma questo non era abbastanza per noi.
Quindi è appena nata l'idea di un plugin, hanno rapidamente inserito i requisiti minimi per questo e hanno iniziato a svilupparsi. Solo una persona, Marat Sadretdinov , che non ha mai scritto nulla per Bitbucket e non ha funzionato con la sua API, ci ha fornito un prototipo funzionante in un mese (ha scritto nel suo tempo libero). La priorità più alta era il requisito: ottenere un elenco di PR pronti a influenzare. Quali criteri abbiamo fissato:
  1. l'assemblea ha avuto successo;
  2. gli esperti necessari hanno messo l'approvazione (in futuro hanno combinato questo in etichette, di cui parlerò di seguito).

Come ha funzionato:
PR è stato creato >> Viene scritto un commento prova questo per favore >> Il nostro plug-in blocca il pulsante Unisci e il plug-in github monitora i commenti e avvia un lavoro su Jenkins >> Jenkins invia successo / fallimento al termine >> Il plug-in attiva il pulsante Unisci se tutti i criteri hanno successo >> " God mode user "inietta il codice, ogni volta che diventa un po' più vecchio.
Qualunque cosa. Da una a due settimane per il debug, la correzione di bug, i ritardi tra Jenkins e Bitbucket (il polling di tutti i PR ogni secondo era difficile, perché il plug-in ha scansionato tutti i commenti). E evviva! Le domande di sviluppo rotte sono sparite.
Ma poi le cose sono diventate ancora più interessanti, i responsabili dello sviluppo e gli sviluppatori avidi volevano "grasso".
  1. Rimuoviamo la frase prova questo per favore ed eseguiamolo automaticamente.
  2. E se una persona ha aggiornato il suo PR, devi battere l'assemblea precedente, iniziarne una nuova.
  3. E in quale sequenza per eseguirlo, c'è già una coda per Jenkins, quindi si alzerà alla fine della coda?
  4. Versiamolo in automatico! Non premere con le mani.
  5. Creiamo etichette da appendere alle PR secondo regole diverse, inizialmente gialle. Non appena diventano tutti verdi, viene versato PR.
  6. Lascia che gli esperti di Telegram scrivano se hanno un nuovo PR o non si riversano per più di due giorni, ecc.
  7. Non eseguire build finché non sono state raccolte tutte le approvazioni
  8. Se l'assemblea ha avuto luogo, ma molto tempo fa (una settimana o più), ad es. "Vecchio" PR, quindi devi scaricare l'etichetta del successo.

Volevamo molto, lascia che ti dica cosa abbiamo ottenuto.

etichette

Cominciamo con l' esperto di etichetta principale.
C'è un gruppo di esperti, prima di tutto gli sviluppatori più esperti del progetto, che conoscono le date di rilascio, la dipendenza e l'impatto del codice, gli approcci e le pratiche generali e, naturalmente, come scrivere al meglio il codice .
squadra .
L'etichetta della tua squadra. Il numero minimo di approvazioni dal tuo team è impostato. Non deve essere uno sviluppatore o un soprannome js, se il PR è nell'interfaccia utente. L'obiettivo principale è che il team confermi che lo sviluppo si sta muovendo nella direzione pianificata. A volte potevano essere sviluppatori più esperti che, prima degli esperti, fornivano commenti al proprio collega.
arco
Ci siamo inventati una tale etichetta per noi stessi quando il nucleo, i componenti comuni, le utilità stavano cambiando. Ciascuna di queste PR di solito interessava molti moduli e pagine e poteva interrompere in modo significativo la funzionalità. Era determinato dalla consueta struttura regolare del progetto (cartella src/Core, src/Common, ecc.)
prCheck
Il marchio tecnologico più importante. Garanzia di affidabilità. Nel repository dell'interfaccia utente, questi sono tslint, lesslint, jsonlint, typescript, webpack, un tempo anche test e2e per groovy. Indietro - compilazione, test di integrazione API. Tutto è nella finestra mobile.
oracle , security , admin , devops
Esperti altamente specializzati nei loro campi.
sonar
Questo è Sonar, sul retro. Scansiona il codice, avvia le attività per le regole che hai adottato sul progetto.
predvnedrezh
Un'etichetta speciale per il periodo "Predvnedrezha", quando l'iniezione è sul naso (da una a due settimane) e nulla può essere iniettato. E non stiamo versando nulla. Quasi. Bene, hai reso l'idea ;)
not_task, not_story, not_bug, not_test
Etichette con saluti da Jira. Il PR ha sempre collegamenti alle attività di Jira, perché il commit non può essere eseguito senza specificare il numero dell'attività (penso che molte persone sul server si impostino di tali hook git). Il plugin esamina solo il tipo di attività in Jira. Quindi questa etichetta dice che il codice è governato da qualcos'altro, non da quello che ti aspetti.
css
Dice che PR ha file di stile, abbiamo bisogno di un guru di stile, layout e design.
Questo posto potrebbe essere la tua etichetta
Abbiamo anche implementato la possibilità di aggiungere manualmente le etichette (se alcune regole non possono essere regolate), l'autore del PR o l'esperto stesso potrebbero aggiungere più esperti (anche più esperti!).
Le etichette possono anche essere rese facoltative, non bloccano il pulsante Unisci.

Revisori predefiniti

Un'altra abilità interessante del plugin è l'assegnazione automatica di esperti. Prima del plugin, ogni sviluppatore selezionava esperti, compagni di squadra e altri i cui interessi erano toccati dalla rispettiva etichetta. All'inizio era solo una roulette russa, con un piccolo bancone all'interno. Se la regola di almeno due approvazioni di esperti funziona nel tuo repository, sono stati selezionati tre esperti da tutti loro.
Perché scegliere due o tre esperti per le PR, chiedi? Perché non assegnare l'intero elenco a ciascun PR? Chi può - guarderà. Ma, come si suol dire, "comune significa nessuno". Bitbucket ha un campanello con le notifiche e se abbiamo 50 PR al giorno, allora ogni esperto (ad esempio, ce ne sono 10) doveva costantemente "portare" questo contatore a zero. Era quasi impossibile (considerando che anche gli esperti scrivono codice), di nuovo si è posta la questione di demoralizzare la squadra. Il plugin ci ha salvati tutti.
Poi abbiamo aggiunto la possibilità di disabilitare l'esperto (vacanze, malattia) e l'introduzione di un programma di lavoro personale. Alcuni team ed esperti sono in altre città. Ma quando il plugin non ne ha tenuto conto, si è scoperto che lo sviluppatore ha creato un PR alle 5 del mattino, ora di Mosca, e gli sono stati assegnati 2 moscoviti che sono arrivati ​​alle 10 ora di Mosca. Anche se c'erano esperti che potevano guardare subito questo PR.

Priorità delle approvazioni o come affrontare il nepotismo

In uno dei repository del server, volevano un gadget come priorità (o peso) delle approvazioni. Cos'è?
Hai un esperto (diciamo Mario) che fa parte della squadra (diciamo Nintendo). Un collega organizza le pubbliche relazioni e Mario approva e approva due etichette contemporaneamente: nintendo_team & expert. Sembra normale, è un esperto. Responsabile di questo codice, ma ci sono ancora sospetti. Abbiamo deciso di non disturbare nel nostro repository, ma in un altro lo volevamo. Abbiamo dato all'etichetta del comando una priorità più alta e quindi gli esperti di questa squadra non possono inverdire l'esperto. È divertente, ma il problema del nepotismo tra i team (circa 2 team Nintendo e Dendy) non è stato risolto :) O forse no...

Club di richieste pull dipendenti

Abbiamo anche, e non solo noi, una tale necessità: esporre le PR dipendenti su UI e Back contemporaneamente, con modifiche API simultanee, ad esempio, e controllando l'intera applicazione sul nuovo codice. Per fare ciò, abbiamo ideato una revisione del plug-in "PR dipendenti e loro influenza simultanea". In PR, inserisci un collegamento, quale PR in un altro repository di cui hai bisogno, e l'assembly verrà raccolto contemporaneamente dal tuo ramo e dal ramo del PR dipendente. Aiuta molto quando cambi il modello API in client + server allo stesso tempo, diciamo che c'era
//before
Dog: {age: number, id: string}
//after
Dog: {age: string, guid: string}
O se modifichi un test in un repository, dove stai cercando un pulsante nel browser con la frase
@FindBy ("// button [text () =" Save "]")
class MyButton
e nel codice dell'interfaccia utente è lo stesso di prima:
<button> Confirm </ button>
quindi è necessario modificare di nuovo in due repository.

Vari pulsanti di comando

C'è un pulsante Riavvia che riavvia i controlli se qualcosa va storto.
C'è un pulsante Ricalcola, Ricicla, se hai bisogno di eliminare tutte le etichette e ricalcolare.
C'è un pulsante "Recensione troppo lunga" per coloro a cui piace segnalare. Viene inviata una lettera "dove andare". Forse aggiungeremo presto un pulsante "Cambia esperti", "Dona 50 rubli" o qualcos'altro di importante e interessante.
Forse questo è tutto ciò che volevo condividere in particolare. Oh, quasi dimenticavo. C'è anche un pannello di amministrazione del plugin.
Grazie per l'attenzione, scrivi le tue domande. Spero che la nostra interessante esperienza ti sia utile nel tuo lavoro.