Tādas tendences kā veiklā attīstība, programmatūras izveide un nepārtraukta integrācija runā par mūsdienu uzņēmuma nepieciešamību programmatūru veidot ļoti efektīvi - un, ja nepieciešams, ieslēgt lielo centu.
Pēdējais manevrs ir tas, kā CloudBees kļuva par uzņēmumu, kāds tas ir šodien. Kādreiz neatkarīgs, publisks mākoņu PaaS nodrošinātājs Java kodētājiem (kuru ļoti novērtēja Endrjū Olivers sadaļā “Kurš freaking PaaS man vajadzētu izmantot?”), CloudBees pirms 18 mēnešiem strauji pagriezās, lai atsāktu darbu kā vadošais Jenkins, ļoti populārās atvērtās programmas, nodrošinātājs avota rīks programmatūras izstrādes procesa vadīšanai.
Saskaņā ar izpilddirektora Sasha Labourey teikto, tā kā Java PaaS nodrošinātājs CloudBees bija "labi pieaudzis", bet "daudzi lielāki puiši ar lielākām pārbaudēm" vilcinājās iesaistīties nestabilā PaaS tirgū, kurā nebija standartizācijas. Tajā pašā laikā Dženkinss pacēlās kā raķete - un Labourey ieraudzīja lielu iespēju, it īpaši tāpēc, ka CloudBees jau piedāvāja Jenkins kā pakalpojumu un jau bija nolīgusi Kohsuke Kawaguchi, Jenkins radītāju. Jenkins piedeva kļuva par galveno ēdienu.
Jenkins juggernaut
Kas slēpjas Dženkinsa popularitātē? Vienkārši sakot, Jenkins ir kļuvis par atvērtā koda standartu devops dev puses pārvaldīšanai, sākot no pirmkoda pārvaldības līdz koda piegādei līdz ražošanai. Saskaņā ar Labourey teikto: "Kopiena Jenkins uzskata par orķestrēšanas un automatizācijas dzinēju ... Es domāju, ka iemesls, kāpēc Jenkins ir kļuvis par faktisko dzinēju, ir tāpēc, ka tas ir ārkārtīgi pieslēdzams." Ir izveidojusies vairāk nekā 1100 spraudņu ekosistēma, kas klientiem ļauj pievienot visdažādākās funkcionalitātes un integrēt Jenkins ar visu, sākot no Active Directory līdz GitHub līdz OpenShift PaaS.
Jenkins ir nepārtrauktas integrācijas (CI) un nepārtrauktas piegādes (CD) risinājums. KI ideja ir apvienot atsevišķu izstrādātāju kodu projektā vairākas reizes dienā un nepārtraukti pārbaudīt, lai izvairītos no pakārtotajām problēmām. CD sper šo soli tālāk, lai nodrošinātu, ka visi apvienotie kodi vienmēr ir gatavi ražošanai. Jenkins ļauj izstrādātājiem maksimāli automatizēt šo procesu - līdz izvietošanai. Labourey sniedz piemēru:
Pieņemsim, ka uzņēmums izmanto šefpavāru vai leļļu izvietošanai AWS. Dženkinss to negrasās aizstāt. Dženkinss zvanīs Puppet, lai to izdarītu - Labi, šeit ir biti, tāpēc sauksim šo Leļļu skriptu un redzēsim, kā tas darbojas. Un Leļļu izpildes iznākumam Jenkinsam būs nozīme, jo tas varētu izlemt izvērst izvietošanu un veikt turpmākas darbības. Mēs to saucam par "cauruļvadu". Tā patiešām ir šī darbību sērija. Tas varētu būt pieci soļi vai 50 soļi.Jenkins kalpo kā darbplūsmas dzinējs, lai pārvaldītu šo CI / CD cauruļvadu no avota līdz piegādei, saka Labourey, taču pa ceļam var tikt aicināti daudzi dažādi rīki, lai veiktu dažādas funkcijas.
Docker ir viens no šiem rīkiem, un Docker kopā ar Jenkins dziļi ietekmē attīstības komandas. Ikviens zina, ka Docker racionalizē attīstību un ievērojami atvieglo ieviešanu, taču Labourey atzīmē, ka tas palīdz arī izstrādātājiem būt godīgiem: viņi vairs nevar vainot kādu nepareizu attīstības vides konfigurāciju, kad būvējums avarē un sadedzina. Fiziskajā mašīnā attīstības vide pakāpeniski tiek sabojāta, netīši izraisot būvju pārtraukumus. Bet, kad jūs kodējat virs senatnīga Docker attēla, jums ir vainojams tikai savs kļūdains kods, kad būvēšana nedarbosies.
Kopā Jenkins un tā integrētā ekosistēma nodrošina koordinējošu programmatūras infrastruktūru veiklai attīstībai un plašākā nozīmē veido “devops iniciatīvas kodolu”, saka Labourey.
Nokļūšana no šejienes
Visa šī automatizācija un devops efektivitāte izklausās lieliski, bet kā ir ar organizācijām, kuras knapi ir apmetušas galvu ap veiklu attīstību? Labourey piedāvā padomus, lai iegremdētos CI / CD:
Es domāju, ka labākais veids, kā to izdarīt, ir sākt ar mazumiņu. Izvēlieties projektu. Nesakiet: "Labi, tagad mēs esam nepārtrauktas piegādes veikals, viss notiek šādi." Sāciet ar komandu, kas vēlas, kas varbūt ir elastīgāka nekā citas komandas, varbūt jaunāki komandas locekļi, kas mazāk iesakņojušies esošajā rīcībā. Izvēlieties vieglu projektu. Nemēģiniet to izmantot kā veidu, kā pateikt, ja tas darbojas, viss darbosies. Nemēģiniet izgāzties; mēģiniet gūt panākumus. Izvēlieties labprātīgu komandu, izvēlieties vieglu projektu un nokļūstiet tur. Šī komanda būs jūsu labākais pārdošanas puisis, jo tagad jūs varat parādīt, ka tas darbojas. Viņi var runāt par to, kā viņu darbs kļuva labāks, jo, atklāti sakot, vecais veids ir garlaicīgs.Daļa no procesa, atzīmē Labourey, ir "iegūt zināšanas, kas klusi sēž cilvēku smadzenēs, un ievietot tās cauruļvadā kā loģiku". Tas nenotiek pa nakti. Bieži vien attīstības organizācijas vispirms sagrābj KI un laika gaitā strādā pie CD.
Attīstības organizācijām parasti ir ļoti atšķirīgas, ļoti specifiskas prasības. Tātad CloudBees piedāvā gan vispārēju, uz abonementiem balstītu SaaS versiju, ko vada CloudBees, gan "privāto SaaS" versiju, kuru klienti var izvietot vai nu AWS, vai Azure (vai lokāli OpenStack), un pielāgot to savam sirdij.
Ir grūti pārvērtēt attīstības procesa organizēšanas, automatizācijas un racionalizācijas nozīmi. CI / CD ir centrālais elements devops, un veiksmīgai devops ieviešanai savukārt ir sekas, kas attiecas ne tikai uz IT, bet arī uz pašu biznesu. Nepārtraukti uzlabojot programmatūru, nepārtraukti tiek uzlaboti produkti un pakalpojumi. Piemēram, Tesla bija nopietna neveiksme, kad viens no modeļiem aizdegās - un programmatūras jaunināšanas ieviešana problēmu novērsa pa nakti.
"Tas ir interesanti, ja jūs saņemat par 10 procentiem lielāku efektivitāti; ja jūs iztērējat 100 miljonus ASV dolāru gadā IT, labi, lieliski - jums ir 10 miljoni dolāru, kurus varat iztērēt kaut kur citur," saka Labourey. "Bet patiesais ieguvums ir tad, kad bizness saprot, ka, izmantojot šos rīkus un veicot darbības veidu, tie var palielināt pārdošanas apjomus par 10 procentiem."
