Computable.nl
  • Thema’s
    • Carrière
    • Innovatie & Transformatie
    • Cloud & Infrastructuur
    • Data & AI
    • Governance & Privacy
    • Security & Awareness
    • Software & Development
    • Werkplek & Beheer
  • Sectoren
    • Channel
    • Financiële dienstverlening
    • Logistiek
    • Onderwijs
    • Overheid
    • Zorg
  • Computable Awards
    • Overzicht
    • Nieuws
    • Winnaars
    • Partner worden
  • Vacatures
    • Vacatures bekijken
    • Vacatures plaatsen
  • Bedrijven
    • Profielen
    • Producten & Diensten
  • Kennisbank
  • Nieuwsbrief

Continuous delivery & deployment en de organisatie

24 juni 2016 - 12:514 minuten leestijdOpinieSoftware & Development
Dennis Doomen
Dennis Doomen

De afgelopen weken heb je meer kunnen lezen over continuous delivery en continuous deployment. In het laatste deel van deze reeks komt het ontwikkelproces aan de orde, want beide werkwijzes hebben behoorlijke impact op de organisatie. En kun je niet wachten om zelf te starten? Lees dan de zeven stappen die je helpen om aan de slag te gaan!

Continuous delivery en/of continuous deployment vereisen beide dat je organisatie snel kan schakelen en mee kan groeien met nieuwe wensen en eisen. En dat werkt natuurlijk niet als je nog volgens een watervalmethodiek werkt. Het zal niet als een verrassing komen dat continuous werken hand in hand gaat met Agile methodieken als Scrum en Kanban.

Veel van de onderliggende engineeringprincipes komen uit Extreme Programming (één van de eerste Agile methodieken). Het iteratieve karakter van Scrum past perfect bij continuous delivery, terwijl het continue proces van Kanban juist weer beter aansluit bij continuous deployment. 

Groeiproces

Ook qua groeiproces klopt dit als een bus. Veel organisaties die voor het eerst in aanraking komen met Agile-softwareontwikkeling beginnen met Scrum. Hoewel ze bijna altijd onderschatten hoeveel impact Scrum heeft op de organisatie, introduceert dat wel de juiste mentaliteit voor continuous delivery.

Daarnaast zie je dat teams die volwassen genoeg zijn, uiteindelijk overgaan op Kanban. Kanban is een wat vrijer proces, zonder een vooraf gedefinieerde planning. Hierbij ligt de nadruk op het beperken van de hoeveelheid werk die tegelijkertijd wordt opgepakt. Er kan nog wel een project aan ten grondslag liggen, maar in de praktijk is elk brokje werk dat het team oppakt een afgebakend geheel. Een prima combinatie met continuous delivery dus. Helemaal als ze dat brokje werk volledig geautomatiseerd in productie kunnen zetten. 

En nu? Aan de slag in zeven stappen!

Is je interesse gewekt voor continuous development en deployment, maar staat je organisatie hier nog erg ver vandaan? Dan is het slim om stap voor stap te starten. Wat mij betreft is dit de beste aanpak:

  1. Stap over op Git. Zonder Git is de rest wel te doen, maar een stuk moeilijker. Probeer maar eens met Team Foundation Server verschillende branches te monitoren, zonder elke keer de Team Build-instellingen aan te moeten passen.
  2. Start met automatiseren van het build process. Heb je dit voor elkaar, dan is het een stuk makkelijker om andere onderdelen gecontroleerd te automatiseren.
  3. Zorg dat het build process flexibel genoeg is om alle configuratie- en infrastructuurinstellingen te ondersteunen die de beheerafdeling normaliter handmatig uitvoert. Zo hoef je straks geen handmatige stappen meer uit te voeren, buiten het op de juiste plek zetten van de dll’s of executables.
  4. Vervang eventuele database scripts met een library die schema’s vanuit code kan bijwerken naar de laatste versie. Fluent Migrator en Entity Framework kennen beide zulke functies.
  5. Begin met het herstructuren van de broncode (ook wel refactoring genoemd) en zorg dat je meer en meer aspecten automatisch test vanuit het build process. Overweeg ook om onderdelen van het systeem los te trekken, zodat je die apart kunt beheren en ontwikkelen.
  6. Kies een releasestrategie en volg die ook, eventueel in combinatie met automatische versionering met behulp van Gitversion.
  7. Begin met het schrijven van tijdelijke karaktertesten die als vangnet dienen voor de veranderingen die nodig zijn om continuous delivery of deployment mogelijk te maken. 

Bestaande patronen doorbreken

Het mooie van alle in dit artikel genoemde werkwijzen, is dat ze ieder al een heel specifiek probleem oplossen. Continuous delivery kan een doel op zich zijn, maar het is de weg ernaartoe die het grote verschil maakt. In tegenstelling tot veel alles-of-niets principes zoals bijvoorbeeld Scrum, zijn het de individuele stappen die je softwareontwikkeling naar een hoger plan brengen.

En hoewel er behoorlijk wat technische uitdaging zit in het introduceren van deze nieuwe kijk op softwareontwikkeling, is dat niet de grootste uitdaging van het geheel. Wat veel lastiger zal zijn, is het doorbreken van de bestaande patronen. Zeker als verantwoordelijkheden nog verdeeld zijn over verschillende – mogelijk zelfs fysiek gescheiden – afdelingen. Maar als je dat punt eenmaal voorbij bent, vraag je je waarschijnlijk af hoe je ooit überhaupt zonder kon werken.

Continuous delivery: het pijnloze productieproces

Continuous deployment: kan het nog pijnlozer?

Deel

    Inschrijven nieuwsbrief Computable

    Door te klikken op inschrijven geef je toestemming aan Jaarbeurs B.V. om je naam en e-mailadres te verwerken voor het verzenden van een of meer mailings namens Computable. Je kunt je toestemming te allen tijde intrekken via de af­meld­func­tie in de nieuwsbrief.
    Wil je weten hoe Jaarbeurs B.V. omgaat met jouw per­soons­ge­ge­vens? Klik dan hier voor ons privacy statement.

    Whitepapers

    Computable.nl

    Design Sprints: 4 dagen van idee naar prototype

    Hoe zet je in vier dagen tijd een gevalideerd prototype neer met Design Sprints?

    Computable.nl

    Resultaatgericht Samenwerken (RGS).

    RGS is een gestructureerde methode die vastgoedprofessionals direct ondersteunt bij kwaliteitsverbetering, kostenefficiëntie en verduurzaming.

    Computable.nl

    De principes van cloud-native techniek

    Cloud-native technologieën voegen flexibiliteit, schaalbaarheid en beveiliging toe en verlagen de operationele kosten voor de IT-omgeving. Hoe dragen Kubernetes, KEDA en AKS hieraan bij?

    Meer lezen

    Computable.nl
    OpinieSoftware & Development

    Continuous deployment: kan het nóg pijnlozer?

    Computable.nl
    OpinieSoftware & Development

    Continuous delivery: het pijnloze productieproces

    puzzel
    OpinieSoftware & Development

    DevOps krijgt vorm met Continuous Testing

    Computable.nl
    OpinieInnovatie & Transformatie

    Combineer BPM en Continuous Delivery

    10 reacties op “Continuous delivery & deployment en de organisatie”

    1. Pa Va Ke schreef:
      14 juli 2016 om 09:33

      Na het lezen van stap 1 krijg ik toch een klokken-klepel-verhaal gevoel.
      GIT is een versiebeheers systeem, niets meer, niets minder. Het monitoren van meerdere branches gebeurt vanuit een bouwomgeving (bijv. Bamboo of Jenkins). Dit zijn wezenlijk andere tools.
      Ergo, je kunt Team Foundation Server gebruiken met een GIT repository onder de motorkap. Daarmee los je het (vermeende) probleem wat genoemd wordt niet op.

      Overigens kun je ook met TFS meerdere parallele streams monitoren. Maar ook met tools als Rational Team Concert en zelfs met SubVersioN kun je dit doen. En als je een beetje goed bent in scripting, draai je je hand er niet voor om dit met good old ClearCase te realiseren.

      Ik zal eens kijken of ik daar wat leuks over kan schrijven

      Login om te reageren
    2. Dennis Doomen schreef:
      14 juli 2016 om 16:36

      Beste Pa Va Ke,

      Dan heb je waarschijnlijk zelf nog niets met Git gedaan. Git is weliswaar ‘maar’ een versiebeheersysteem, maar het feit dat het gedecentraliseerd werkt, branching en merging volledig pijnloos werkt (in tegenstelling tot TFS’s eigen versiebeheersystem), en dat er een enorme set van tools ontstaan zijn die heel veel van de ‘oude’ problemen oplossen kan ik zelf onderschrijven. TFS heeft tegenwoordig wel ondersteuning voor Git, maar mist de cruciale functionaliteit die nodig is om een organisatie verder te schalen. Maar goed, dit ga je pas zien als je er zelf mee aan de slag gaat.

      Het doel van deze drie artikelen was om te laten zien wat je zelf kunt doen om de eerste stappen naar CI/CD te nemen. Het beschrijft vele ingredienten die op zichzelf al heel nuttig zijn, maar die als geheel de complete manier van werken kunnen veranderen.

      Login om te reageren
    3. Henri Koppen schreef:
      14 juli 2016 om 17:16

      Ik heb met verschillende source code versioning systemen gewerkt, GIT vind ik de lastigst om mee te werken, maar ook de krachtigste.

      Ben benieuwd naar je artikel PaVaKe, maar deze vond ik ook wel te verteren. Hopelijk komen er ook nog specifieke artikelen naar aanleiding van de details waarover je schrijft Dennis.

      Login om te reageren
    4. Pa Va Ke schreef:
      14 juli 2016 om 18:12

      Beste Dennis

      Verkeerde aanname, ik werk momenteel dagelijks met GIT. Helaas nog niet de tijd gehad om alle ins en outs te verkennen. Wel heb ik wat meer vergelijkingsmateriaal dan alleen TFS (ClearCase, RTC en SVN). Dito voor bouwomgevingen (Jenkins, TFS, RTC, Electric Commander, BuildForge)

      Mijn doel is overigens niet om GIT (of wel ander tool dan ook) af te kraken, maar om duidelijk te maken dat je enerzijds naast GIT wat meer nodig hebt (bijv. de atlassian suite), en dat er anderzijds ook andere tools zijn waarmee je CI/CD kunt doen.

      Login om te reageren
    5. Dennis Doomen schreef:
      14 juli 2016 om 19:22

      @Henri Koppen, zie http://www.continuousimprover.com. Over bijna elk aspect heb ik al apart geblogged.

      @Pa Va Ke, zie ook specifiek deze post http://www.continuousimprover.com/2016/02/how-git-can-help-you-prevent-monolith.html. Ik heb met eigen ogen gezien dat Git je hele manier van ontwikkelen op de schop gaat gooien. Dat het alleen maar een versiebeheersysteem is naar mijn mening een van de grootste misvattingen. Ik heb zelf jaren met ClearCase en TFS gewerkt (en daarvoor met SVN).

      Login om te reageren
    6. Pa Va Ke schreef:
      14 juli 2016 om 19:41

      @Dennis: bepaalt het CM omgeving de architectuur en de manier van werken, of bepalen de architectuur en manier van werken de inrichting van je CM omgeving?

      De laatste jaren zie ik een trend die naar het eerste neigt, maar volgens mij zou het tweede leidend moeten zijn.

      Login om te reageren
    7. Dennis Doomen schreef:
      14 juli 2016 om 19:56

      @PA VA KE, CM?

      Login om te reageren
    8. Pa Va Ke schreef:
      14 juli 2016 om 20:03

      @Dennis: CM, configuration management (sorry, beroepsdeformatie).

      Login om te reageren
    9. Johan Duinkerken schreef:
      15 juli 2016 om 07:45

      @PaVaKe
      Denk niet dat Dennis de doelgroep heeft van de ontwikkel clubs die wel voorop lopen met deze nieuwe ontwikkelingen. Alhoewel is voor IMHO elk zichzelf respecterende ontwikkelaar CI/CD al gesneden koek en het hoor een vanzelfsprekendheid.
      Denk dat hij eerder de organisaties aanschrijft die nog met waterfall, oudere VCS of nog erger houtje touwtje oplossingen werken. En die zullen zich echt nog eens een keer goed achter de oren moeten krabben of ze toch maar eens niet mee moeten gaan met de innovaties en zorgen dat ze weer competitief worden want de bottomline is dat je met CI/CD (mits goed toegepast uiteraard) je meer effectief kan werken.

      Login om te reageren
    10. Jasper P schreef:
      15 juli 2016 om 08:51

      Beste Johan & Dennis Doomen,
      Onze ‘jongens en meisjes’ die er op uitgestuurd worden naar de NCOI – HBO Informatica opleiding (ja, van 20 tot 60 jaar, ze gaan allemaal, wij betalen – 2 dagen (1 lesdag – 1 studiedag per week worden doorbetaald natuurlijk).
      Als ik roep delivery & deployment krijg ik vraagtekens terug… (?)

      Wat te doen, Engelse les?
      Ik ga ermee door hoor, maar ’t kost toch totaal snel 4.000 euro per werknemer. Da’s veel geld als je er veel hebt en niemand weet waar het overgaat.

      delivery & deployment. Tja…

      Login om te reageren

    Geef een reactie Reactie annuleren

    Je moet ingelogd zijn op om een reactie te plaatsen.

    Populaire berichten

    Meer artikelen

    Footer

    Direct naar

    • Carrièretests
    • Kennisbank
    • Planning
    • Computable Awards
    • Magazine
    • Abonneren Magazine
    • Cybersec e-Magazine

    Producten

    • Adverteren en meer…
    • Jouw Producten en Bedrijfsprofiel
    • Whitepapers & Leads
    • Vacatures & Employer Branding
    • Persberichten

    Contact

    • Colofon
    • Computable en de AVG
    • Service & contact
    • Inschrijven nieuwsbrief
    • Inlog

    Social

    • Facebook
    • X
    • LinkedIn
    • YouTube
    • Instagram
    © 2025 Jaarbeurs
    • Disclaimer
    • Gebruikersvoorwaarden
    • Privacy statement
    Computable.nl is een product van Jaarbeurs