Trender som smidig utvikling, devops og kontinuerlig integrasjon taler til det moderne foretakets behov for å bygge programvare hypereffektivt - og om nødvendig å slå på en krone.
Sistnevnte manøver er hvordan CloudBees ble selskapet det er i dag. En gang en uavhengig, offentlig Cloud PaaS-leverandør for Java-kodere (høyt rangert av Andrew Oliver i "Hvilken freaking PaaS skal jeg bruke?"), Svingte CloudBees skarpt for 18 måneder siden for å starte på nytt som den ledende leverandøren av Jenkins, en svært populær open kildeverktøy for å administrere programvareutviklingsprosessen.
I følge administrerende direktør Sasha Labourey hadde CloudBees som en Java PaaS-leverandør vokst pent, men "mange av de større gutta med større sjekker" var nølende med å forplikte seg i et ustabilt PaaS-marked som manglet standardisering. Samtidig tok Jenkins avgang som en rakett - og Labourey så en stor mulighet, spesielt siden CloudBees allerede tilbød Jenkins som en tjeneste og allerede hadde ansatt Kohsuke Kawaguchi, Jenkins 'skaper. Jenkins tilbehør ble hovedrett.
Jenkins juggernaut
Hva ligger bak Jenkins ’popularitet? Enkelt sagt, Jenkins har blitt åpen kildekodestandard for å administrere dev-siden til devops, fra kildekodeadministrasjon til å levere kode til produksjon. Ifølge Labourey, "Samfunnet ser på Jenkins som en orkestrasjons- og automatiseringsmotor ... Jeg tror grunnen til at Jenkins har blitt de facto-motoren er fordi den er ekstremt pluggbar." Det har dukket opp et økosystem med mer enn 1100 plug-ins, som gjør det mulig for kunder å legge til alle mulige funksjoner og integrere Jenkins med alt fra Active Directory til GitHub til OpenShift PaaS.
Jenkins er en kontinuerlig integrasjonsløsning (CI) og kontinuerlig levering (CD). Ideen med CI er å slå sammen kode fra individuelle utviklere til et prosjekt flere ganger per dag og teste kontinuerlig for å unngå nedstrøms problemer. CD tar dette et skritt videre for å sikre at all sammenslått kode alltid er i produksjonsklar tilstand. Jenkins gjør det mulig for utviklere å automatisere denne prosessen så mye som mulig - opp til distribusjonspunktet. Labourey gir et eksempel:
Si at et selskap bruker Chef eller Puppet til å distribuere på AWS. Jenkins kommer ikke til å erstatte det. Jenkins kommer til å ringe Puppet for å gjøre det - OK, her er bitene, så la oss kalle dette Puppet-skriptet og se hvordan det fungerer. Og produksjonen av Puppets henrettelse kommer til å ha betydning for Jenkins fordi den kan bestemme seg for å rulle ut distribusjonen og ta ytterligere tiltak. Vi kaller det "rørledningen." Det er virkelig denne serien av trinn. Det kan være fem trinn, eller det kan være 50 trinn.Jenkins fungerer som arbeidsflytmotoren for å administrere denne CI / CD-rørledningen fra kilde til levering, sier Labourey, men underveis kan det kalles på mange forskjellige verktøy for å utføre forskjellige funksjoner.
Docker er et av disse verktøyene, og Docker i forbindelse med Jenkins har en dyp effekt på utviklingsteam. Alle vet at Docker effektiviserer utviklingen og gjør distribusjonen mye enklere, men Labourey bemerker at det også hjelper å holde utviklerne ærlige: De kan ikke lenger skylde på feil konfigurasjon av utviklingsmiljøet når en bygning krasjer og brenner. På en fysisk maskin blir utviklingsmiljøet gradvis ødelagt, noe som forårsaker at bygninger går i stykker. Men når du koder på toppen av et uberørt Docker-bilde, har du bare din egen feilkode å klandre når bygg ikke kjører.
Sammen gir Jenkins og dets integrerte økosystem den koordinerende programvareinfrastrukturen for smidig utvikling og danner bredere "kjernen i devops-initiativet," sier Labourey.
Komme dit herfra
All denne automatiseringen og effektiviteten høres bra ut, men hva med organisasjoner som knapt har pakket hodet rundt smidig utvikling? Labourey gir råd for å vasse inn i CI / CD:
Jeg tror den beste måten å gjøre det på er å starte i det små. Velg et prosjekt. Ikke si, "OK, nå er vi en kontinuerlig leveringsbutikk, alt går slik." Start med et team som er villig, det er kanskje mer fleksibelt enn andre lag, kanskje nyere teammedlemmer, mindre forankret i den eksisterende måten å gjøre ting på. Velg et enkelt prosjekt. Ikke prøv å bruke det som en måte å si at hvis den fungerer, vil alt fungere. Ikke prøv å feile; prøv å lykkes. Velg et villig team, velg et enkelt prosjekt, kom dit. Dette teamet kommer til å bli din beste salgsmann, for nå kan du vise at det fungerer. De kan snakke om hvordan jobben deres ble bedre, fordi den gamle måten ærlig talt er kjedelig.En del av prosessen, bemerker Labourey, er å "trekke ut kunnskapen som sitter stille i folks hjerner og legge den i rørledningen som logikk." Det skjer ikke over natten. Ofte begynner utviklingsorganisasjoner med å hamre ut CI og arbeide seg mot CD over tid.
Utviklingsorganisasjoner har en tendens til å ha vidt forskjellige, svært spesifikke krav. Så CloudBees tilbyr både en generisk, abonnementsbasert SaaS-versjon som drives av CloudBees og en "privat SaaS" -versjon, som kundene kan distribuere på enten AWS eller Azure (eller lokalt på OpenStack) og tilpasse den etter eget hjerte.
Det er vanskelig å overvurdere viktigheten av å organisere, automatisere og effektivisere utviklingsprosessen. CI / CD er sentralt i devops, og en vellykket implementering av devops har i sin tur implikasjoner som går utover IT til selve virksomheten. Kontinuerlig forbedring av programvare forbedrer kontinuerlig produkter og tjenester. Tesla hadde for eksempel et alvorlig tilbakeslag med en av modellene som tok fyr - og å rulle ut en programvareoppgradering løste problemet over natten.
"Det er interessant hvis du får 10 prosent mer effektivitet. Hvis du bruker 100 millioner dollar i året på IT, vel bra - du har 10 millioner dollar du kan bruke et annet sted," sier Labourey. "Men den virkelige fordelen er når virksomheten innser at ved å utnytte disse verktøyene og den måten å gjøre ting på, kan de øke salget med 10 prosent."
