Tendenser som agil udvikling, devops og kontinuerlig integration taler til den moderne virksomheds behov for at opbygge software hypereffektivt - og om nødvendigt at tænde en krone.
Sidstnævnte manøvre er, hvordan CloudBees blev det firma, det er i dag. Engang en uafhængig, offentlig cloud-PaaS-udbyder til Java-kodere (bedømt højt af Andrew Oliver i "Hvilken freaking PaaS skal jeg bruge?"), Drejede CloudBees sig kraftigt for 18 måneder siden for at genstarte som den førende udbyder af Jenkins, en meget populær open kilde værktøj til styring af softwareudviklingsprocessen.
Ifølge administrerende direktør Sasha Labourey havde CloudBees som Java PaaS-udbyder været "vokset pænt", men "mange af de større fyre med større checks" var tøvende med at begå sig i et ustabilt PaaS-marked, der manglede standardisering. Samtidig startede Jenkins som en raket - og Labourey så en stor mulighed, især da CloudBees allerede tilbød Jenkins som en tjeneste og allerede havde hyret Kohsuke Kawaguchi, Jenkins 'skaber. Jenkins side skål blev hovedretten.
Jenkins juggernaut
Hvad ligger bag Jenkins 'popularitet? Kort sagt, Jenkins er blevet open source-standarden til styring af devops dev side, fra kildekodestyring til levering af kode til produktion. Ifølge Labourey, "Fællesskabet ser på Jenkins som en orkestrations- og automatiseringsmotor ... Jeg tror, at grunden til, at Jenkins er blevet de facto-motoren, er fordi den er ekstremt tilslutbar." Der er opstået et økosystem med mere end 1.100 plug-ins, der gør det muligt for kunder at tilføje alle mulige funktioner og integrere Jenkins med alt fra Active Directory til GitHub til OpenShift PaaS.
Jenkins er en kontinuerlig integration (CI) og kontinuerlig levering (CD) løsning. Idéen med CI er at flette kode fra individuelle udviklere til et projekt flere gange om dagen og teste kontinuerligt for at undgå downstream-problemer. CD tager dette et skridt videre for at sikre, at al flettet kode altid er i en produktionsklar tilstand. Jenkins gør det muligt for udviklere at automatisere denne proces så meget som muligt - op til implementeringsstedet. Labourey giver et eksempel:
Sig, at et firma bruger Chef eller Puppet til at implementere på AWS. Jenkins vil ikke erstatte det. Jenkins vil kalde Puppet til at gøre det - OK, her er bitene, så lad os kalde dette Puppet-script og se, hvordan det fungerer. Og output af Puppet's eksekvering kommer til at betyde noget for Jenkins, fordi det muligvis beslutter at rulle implementeringen og tage yderligere handlinger. Vi kalder det "rørledningen." Det er virkelig denne række trin. Det kan være fem trin, eller det kan være 50 trin.Jenkins fungerer som workflowmotoren til at styre denne CI / CD-pipeline fra kilde til levering, siger Labourey, men undervejs kan mange forskellige værktøjer opfordres til at udføre forskellige funktioner.
Docker er et af disse værktøjer, og Docker har sammen med Jenkins en dybtgående effekt på udviklingsteams. Alle ved, at Docker strømliner udviklingen og gør implementeringen meget lettere, men Labourey bemærker, at det også hjælper med at holde udviklere ærlige: De kan ikke længere bebrejde en eller anden forkert konfiguration af udviklingsmiljøet, når en bygning går ned og brænder. På en fysisk maskine bliver udviklingsmiljøet gradvist ødelagt og forårsager uforvarende bygninger at bryde. Men når du koder oven på et uberørt Docker-billede, har du kun din egen fejlbehæftede kode at bebrejde, når builds ikke kører.
Sammen leverer Jenkins og dets integrerede økosystem den koordinerende softwareinfrastruktur til agil udvikling og udgør mere "kernen i devops-initiativet", siger Labourey.
At komme derfra herfra
Al denne automatisering og devops effektivitet lyder godt, men hvad med organisationer, der næppe har pakket hovedet omkring agil udvikling? Labourey tilbyder råd til at vade ind i CI / CD:
Jeg tror, at den bedste måde at gøre det på er at starte i det små. Vælg et projekt. Sig ikke, "OK, nu er vi en kontinuerlig leveringsbutik, alt går sådan." Start med et team, der er villigt, det er måske mere fleksibelt end andre hold, måske nyere teammedlemmer, mindre forankret i den eksisterende måde at gøre tingene på. Vælg et let projekt. Forsøg ikke at bruge det som en måde at sige, at hvis den ene fungerer, fungerer alt. Forsøg ikke at fejle; prøv at få succes. Vælg et villigt team, vælg et let projekt, kom derhen. Dette team bliver din bedste salgskvinde, for nu kan du vise, at det fungerer. De kan tale om, hvordan deres job blev bedre, for ærligt talt er den gamle måde kedelig.En del af processen, bemærker Labourey, er at "udvide den viden, der sidder stille i folks hjerner og lægge den i rørledningen som logik." Det sker ikke natten over. Ofte begynder udviklingsorganisationer med at hamre CI ud og arbejder sig mod CD over tid.
Udviklingsorganisationer har tendens til at have meget forskellige, meget specifikke krav. Så CloudBees tilbyder både en generisk, abonnementsbaseret SaaS-version, der køres af CloudBees, og en "privat SaaS" -version, som kunderne kan distribuere på enten AWS eller Azure (eller lokalt på OpenStack) og tilpasse den til deres hjerteindhold.
Det er svært at overvurdere vigtigheden af at organisere, automatisere og strømline udviklingsprocessen. CI / CD er central for devops, og en vellykket implementering af devops har til gengæld konsekvenser, der strækker sig ud over IT til selve virksomheden. Kontinuerlig forbedring af software forbedrer løbende produkter og tjenester. Tesla havde for eksempel et alvorligt tilbageslag med en af sine modeller, der brændte - og udrulning af en softwareopgradering løste problemet natten over.
"Det er interessant, hvis du får 10 procent mere effektivitet. Hvis du bruger 100 millioner dollars om året i it, godt godt - du har 10 millioner dollars, kan du bruge et andet sted," siger Labourey. "Men den virkelige fordel er, når virksomheden indser, at ved at udnytte disse værktøjer og den måde at gøre ting på, kan de øge salget med 10 procent."
