Resistent med god anledning

Som erfaren utvecklare är jag lat av naturen. Låt mig faktiskt omformulera det: Jag är inte längre intresserad av att skriva vissa delar av programmets kodbas. Om du är som jag ser du fram emot de utmanande aspekterna av vad som behöver utvecklas och inte de delar du troligtvis har skrivit gång på gång.

Tyvärr finns det för de flesta applikationer av en viss storlek och komplexitet en kategori av kod som måste finnas: den intetsägande koden . Själva blandkoden är oerhört viktig, men ganska överflödig. Visst, varje domän sätter sin egen smak på intetsägande kod, men kärnbitarna i de flesta appar ser lika ut. Även om det är nödvändigt, är intetsägande kod förutsägbar och saknar den pizzazz (läs: utmaning) som de flesta utvecklare söker. Koden vi vill arbeta med är dock värdelös utan den intetsägande koden.

Så vi behöver den intetsägande koden och vilja under en tid. Skulle det inte vara bra om det bara dök upp när vi behöver det? Oavsett om någon annan skriver det, eller om det visas med en knapptryckning, spelar det ingen roll - vi vill se intetsägande kod som alla andra återanvändbara, robusta och pålitliga API: er.

Steg saknas

Oavsett var din åsikt ligger angående Sprint Zero, låt oss komma överens om att det finns en tid mellan att räkna ut vad / hur man börjar DevOps och faktiskt göra DevOps.

Med alla mogna verktyg för att hjälpa till före och under DevOps-faser är det inte konstigt att Sprint Zero ofta förbises eller ses som en beredningsformalitet.

Sedan början av 2000-talet har det gjorts många försök att standardisera begreppet mjukvarumodeller och arkitekturer. En sådan standard är Model Driven Architecture (MDA), ett koncept utvecklat av Object Management Group (OMG) som definierar en oberoende mellan en modell och den tekniska miljön där den realiseras.

Under samma tid som MDA: s utveckling dök applikationsgeneratorer överallt. Applikationsgenerering har alltid hållit löften som ofta inte har hållits. I teorin är det bra att skapa kod. I praktiken ger de flesta marginellt värde, ofta saknar flexibilitet för att hålla jämna steg med ständigt föränderliga modellbeskrivningar, teknikstackar, applikationsramar och distributionsplattformar.

Processen med Generation-as-a-Service måste visas som de andra DevOps-tjänster vi har vant oss vid. Det måste vara effektivt, men inte påträngande. Den borde ha en inlärningskurva som är låg till ingen. Det bör vara tillgängligt som både en applikation och ett programmatiskt API. Det bör sömlöst passa in i alla befintliga traditionella DevOps-process, vare sig det är smidigt i sin natur eller på annat sätt. Det viktigaste av allt är att ansträngningen att ge input till tjänsten och utnyttja dess produktion bör vara försumbar jämfört med dess fördelar.

En annan betrodd tjänst

Mer än någonsin är mjukvaruutveckling beroende av externa tjänster. Vi litar på GitHub och Bitbucket för våra källkontrollbehov, JIRA för att hantera vår problemspårning och Docker Hub för att säkra våra containerbilder.

Vi har integrerat Jenkins, Chef, Puppet, Maven och många andra tekniker i DevOps. De har blivit så vanliga att att driva ett betydande projekt utan dem kommer att visa hur beroende vi är. Anledningen är enkel: De fungerar och fyller ett behov i DevOps-processen. När de är kedjade tillsammans bildar de också en kontinuerlig process för appintegration och leverans.

Vilken fantastisk sak.

Så är det en sträcka att tänka på applikationsgenerering på samma sätt? Var och en av de nämnda tjänsterna och teknologierna har inputbehov och ger en utgång som en tjänst. Om tillräckligt strukturerad input kan samlas in utan betydande ansträngning, och om en beskrivning av en målteknologiback kan specificeras, kan det vara möjligt att se applikationsgenerering som en riktig DevOps-tjänst.

Ännu bättre...

Vi behöver en ingenjör som ansvarar för att förvandla affärsmodeller och tekniska modeller till vår intetsägande kod. En enda pålitlig teknisk resurs som kan ta vår "beställning" och har plattformen och kompetensmakten att ge oss vad vi behöver när vi behöver det, så vi kan prioritera och mobilisera. För att verkställa återanvändning, skulle denna tekniker veta vilka tidigare order som var samma eller liknande vår beställning. Denna ingenjör skulle lita på en plattform för att slå samman affärs- och tekniska modeller för att omedelbart generera tiotals till hundratusentals rader med intetsägande kod. Plattformen skulle göra det möjligt för ingenjören att välja mellan en uppsättning företagsstandardiserade templatiserade teknikstackar för att stödja en mängd språk, designmönster, arkitekturer och målmiljö.