Trendi, kot so gibčen razvoj, devops in nenehna integracija, govorijo o potrebi sodobnega podjetja po hiper-učinkoviti gradnji programske opreme - in po potrebi tudi po drobižu.
S tem zadnjim manevrom je CloudBees postal podjetje, ki je danes. Ko je bil neodvisen, javni ponudnik PaaS v oblaku za kodirnike Java (Andrew Oliver ga je visoko ocenil v "Katerega čudnega PaaS-a naj uporabim?"), Se je CloudBees pred 18 meseci močno vrtel in se ponovno zagnal kot vodilni ponudnik Jenkins, zelo priljubljenega izvorno orodje za upravljanje procesa razvoja programske opreme.
Po besedah izvršnega direktorja Sashe Laboureyja je CloudBees kot ponudnik Java PaaS "lepo rasel", toda "veliko večjih ljudi z večjimi čeki" se je obotavljalo, da bi se zavezalo na nestanovitnem trgu PaaS, ki ni imel standardizacije. Hkrati je Jenkins vzletel kot raketa - in Labourey je videl veliko priložnost, zlasti ker je CloudBees Jenkinsa že ponujal kot storitev in je že najel Kohsukeja Kawaguchija, Jenkinsovega ustvarjalca. Jenkinsova priloga je postala glavna jed.
Jenkinsov juggernaut
Kaj je v ozadju Jenkinsove priljubljenosti? Preprosto povedano, Jenkins je postal odprtokodni standard za upravljanje razvojne strani devopsa, od upravljanja izvorne kode do dostave kode v produkcijo. Po mnenju Laboureyja: "Skupnost Jenkinsa vidi kot mehanizem za orkestracijo in avtomatizacijo ... Mislim, da je razlog, zakaj je Jenkins dejansko postal motor, ta, da je izredno vtičljiv." Pojavil se je ekosistem z več kot 1100 vtičniki, ki strankam omogoča, da dodajo vse vrste funkcionalnosti in integrirajo Jenkinsa z vsem, od Active Directory do GitHub-a do OpenShift PaaS.
Jenkins je rešitev za neprekinjeno integracijo (CI) in neprekinjeno dostavo (CD). Ideja CI je združiti kodo posameznih razvijalcev v projekt večkrat na dan in neprekinjeno testirati, da se izognemo nadaljnjim težavam. CD naredi še korak naprej, da zagotovi, da je vsa združena koda vedno v pripravljenosti za proizvodnjo. Jenkins razvijalcem omogoča, da ta postopek čim bolj avtomatizirajo - do točke uvajanja. Labourey ponuja primer:
Recimo, da podjetje uporablja Chef ali Puppet za uvajanje na AWS. Jenkins tega ne bo nadomestil. Jenkins bo poklical Lutko, da to stori - OK, tukaj so deli, zato pokličimo ta lutkovni skript in poglejmo, kako deluje. Rezultat usmrtitve Lutke bo pomemben za Jenkinsa, ker se bo morda odločil, da bo sprožil uvajanje in sprejel nadaljnje ukrepe. Imenujemo ga "plinovod". V resnici gre za to vrsto korakov. Lahko je pet korakov ali pa 50 korakov.Jenkins služi kot mehanizem delovnega toka za upravljanje tega cevovoda CI / CD od vira do dostave, pravi Labourey, toda na tej poti se lahko za izvajanje različnih funkcij zahteva veliko različnih orodij.
Docker je eno izmed teh orodij in Docker skupaj z Jenkinsom močno vpliva na razvojne ekipe. Vsi vemo, da Docker racionalizira razvoj in močno olajša uvajanje, toda Labourey ugotavlja, da pomaga tudi razvijalcem, da ostanejo pošteni: ne morejo več kriviti neke napačne konfiguracije razvojnega okolja, ko zgradba sesuje in gori. Na fizičnem stroju se razvojno okolje postopoma poškoduje in nehote povzroči, da se gradnje pokvarijo. Ko pa kodirate na vrhu neokrnjene slike Dockerja, imate krivdo le za svojo napačno kodo, ki se ne bo izvajala.
Jenkins in njegov integrirani ekosistem zagotavljata usklajevalno programsko infrastrukturo za gibčen razvoj in širše tvorita "jedro pobude devops", pravi Labourey.
Tja od tu
Vsa ta avtomatizacija in učinkovitost devopsa zveni čudovito, kaj pa organizacije, ki so komaj zavile glave okoli okretnega razvoja? Labourey ponuja nasvete za vstavljanje v CI / CD:
Mislim, da je najboljši način za to, da začnemo z majhnimi. Izberite projekt. Ne recite: "V redu, zdaj smo neprekinjena dostava, vse gre po tej poti." Začnite z ekipo, ki je pripravljena, ki je morda bolj prilagodljiva kot druge ekipe, morda novejši člani ekipe, manj vpeti v obstoječi način dela. Izberite enostaven projekt. Ne poskušajte tega uporabiti kot način, da rečete, če ta deluje, bo vse delovalo. Ne poskušajte spodleteti; poskusite uspeti. Izberite pripravljeno ekipo, izberite enostaven projekt, pridite tja. Ta ekipa bo vaš najboljši prodajalec, ker lahko zdaj pokažete, da deluje. Lahko govorijo o tem, kako se je njihova služba izboljšala, saj je, pošteno rečeno, stara pot dolgočasna.Del postopka je, ugotavlja Labourey, "izvleči znanje, ki ljudem mirno leži v možganih, in ga kot logiko spraviti v načrt". To se ne zgodi čez noč. Pogosto razvojne organizacije začnejo tako, da iztisnejo informacijski sistem in se sčasoma potrudijo do CD-ja.
Razvojne organizacije imajo običajno zelo različne, zelo specifične zahteve. Torej CloudBees ponuja tako generično različico SaaS, ki temelji na naročnini, ki jo vodi CloudBees, in "zasebno različico SaaS", ki jo lahko stranke uvedejo v AWS ali Azure (ali lokalno v OpenStack) in jo prilagodijo po svoji meri.
Težko je preceniti pomen organiziranja, avtomatizacije in racionalizacije razvojnega procesa. CI / CD je osrednjega pomena za devops, uspešna implementacija devopsa pa ima posledice, ki presegajo informacijsko tehnologijo in samo poslovanje. Nenehno izboljševanje programske opreme nenehno izboljšuje izdelke in storitve. Tesla se je na primer z enim od svojih modelov resno zalotila - z uvedbo nadgradnje programske opreme je težavo odpravila čez noč.
"Zanimivo je, če dosežete 10 odstotkov večjo učinkovitost; če letno za IT porabite 100 milijonov dolarjev, super - imate 10 milijonov dolarjev, ki jih lahko porabite nekje drugje," pravi Labourey. "Toda resnična korist je, ko podjetje spozna, da lahko z izkoriščanjem teh orodij in takšnega načina poslovanja prodajo poveča za 10 odstotkov."
