4 Software Delivery Mistakes Blocking Your Continuous Delivery

If you ask five experts to define Continuous Delivery, you’ll get six different answers. The responses will range from continuously merging code to a shared repository (i.e., Continuous Integration), to the use of modern delivery tools to manage discrete parts of the pipeline (e.g., provisioning, testing, and deployment), all the way up to delivering multiple releases per day to end users of an application.

But no matter how you define Continuous Delivery, the ultimate goal is to continually ship high-value software to your users. Unfortunately, many organizations are their own worst enemies in this regard.

Below are 4 common mistakes that organizations make when trying to do Continuous Delivery.

1. Focusing on development-centric processes instead of the whole release-to-production pipeline 

But it works on my machine!

Ok, so we can still laugh at this timeworn sentiment—at least when it happens during demos at the end of a sprint. But it’s definitely NOT a laughing matter when a major glitch happens right before—or during—Production launch.

This mindset also might signal that the neither the Development team, nor the organization as a whole, is thinking about software delivery beyond the Continuous Integration stage.

For example, doing a deployment in a testing environment is completely different from deploying to Production. They may seem the same from a technical point of view, but from a process perspective, they are vastly different. Organizations that try to scale their Continuous Delivery implementation through build automation alone will have a hard time achieving success.

Why? Because delivering great software frequently—and at scale—requires adopting a holistic approach on the part of all stakeholders, one that takes into account that the entire pipeline, not just Development, must work as a well-tuned delivery system. A successful Production deployment requires much more than getting the code right in Development. Writing great code is important, but so is:

  • Aligning Development efforts with other parties, like Marketing and Product Management, to understand whether what you’re developing is creating business value
  • Integrating compliance into your pipeline to ensure that you’re adhering to regulations and keeping an audit trail
  • Implementing proper security settings for the application in Production to protect your data and your customers
  • Configuring and managing all operations activities needed to run software successfully in Production, such as changing firewall settings, configuring load balancers, and updating procedures and other paperwork

If your team is focused solely on improving the Continuous Integration side of Continuous Delivery without looking at the whole release pipeline, you will soon hit a wall.

2. Not aiming to deliver software daily

Your developers and product managers might not think that striving for delivery every day is important. They may be used to patterns of work such as hardening sprints, or delivering on a quarterly basis, but these habits can actually hold your team back.

Having a lot of work in parallel and only integrating code at the end of a quarter or a cycle means that merge and functionality conflicts won’t appear until late in the process when problems are harder to fix. While extensive hardening is necessary for verifying all differences, full integration every day or night will help you catch issues quickly. Doing so is vital to the quality of your system.

But more importantly—discovering problems early contributes to your learning cycle. If security vulnerabilities or code smell is introduced, it’s best to have a fast feedback loop to your developer. Integrating continuous testing that runs either daily or nightly will help you avoid making the same mistake twice.

From a cultural perspective, breaking through resistance to daily delivery is not the easiest thing to do. Deep organizational transformation is sometimes required, not only in engineering but also in other parts of the organization.

For example, if your Product Management team is used to two to four deliveries a year, switching to a model with smaller, more frequent deliveries can be really difficult. You have to transform your secondary processes to achieve a goal like this, processes for things like the yearly budgeting cycle, the appraisal and hiring system (which might be very rigid), risk management (which requires enormous effort) and keeping the control framework up to date. Simplifying these processes is hard, but to achieve faster delivery, it’s a necessity.

3. Focusing on the technical pipeline and tools, not the business result

It’s tempting to think that software delivery is all about technology and tools. Unfortunately, those who think this way tend to focus primarily on optimizing software development rather than on all the pieces that come before and after code has been written. As a result, they miss opportunities to maximize the value of that software to customers. Taking a technical approach to Continuous Delivery may be ok for a while, but it will not help you drive more value continuously.

Software delivery is first and foremost a business endeavor involving everyone in the pipeline from Design, Engineering, and Operations to Marketing and Sales. All the people, tools, tasks, and processes exist to drive business value. Harmonizing all these pieces requires expanding your approach to Continuous Delivery from development centered to business-value-streamcentered.

Your goal is to deliver value with your software, time after time. You can automate tasks, but unless business-focused orchestration is driving your pipeline, you won’t be able scale software delivery for your enterprise. Focusing only on the technical aspects of CI/CD will only get you so far. To truly succeed, you need to be laser-focused on the business value of each feature and how it is progressing through each stage in the pipeline.

4. Delaying integration, security, and performance testing until later in the cycle

Finding integration, security, and performance issues just before releasing software is much more expensive than if you catch these issues sooner. And they are harder to fix! That’s because these kinds of problems usually impact the code base much more substantially than functional problems do. Integration, security, and performance issues often require rethinking the architecture because they are deeply entangled with the system. Setting up a continuous feedback cycle to your developers is worth the hard work because it helps you catch these problems early.

Fortunately, release orchestration makes it easier to integrate security and performance testing into the pipeline so you can get immediate results and catch problems early. Xebialabs, for example, offers off-the-shelf integrations with testing tools, such as Sonar, Fortify, and Black Duck.

Security Testing

Security testing has four sides. Three of them, static code scanning, third-party library scanning, and dynamic security testing, can be embedded into, and therefore automated within, your Continuous Delivery pipeline.

The fourth side, penetration testing, most of the time requires a specific environment to deploy to because dynamic security testing frameworks can ruin your complete application. Because penetration testing requires human intervention, a good practice is to run these tests on a regular basis. Some organizations, for example, do them at the same time every day, or run them consistently on a monthly, quarterly, or yearly basis. Others follow a more risk-based approach, and judge whether, based on the impact of the new code, a penetration test is required.

Performance Testing

Running performance tests every night is a good practice. In particular, doing Load testing using data sets that are similar to those of your customers is extremely useful for determining whether the day’s changes impact performance in a good or bad way.

Running extensive performance tests over the weekend may also be useful because you can see how the system behaves under stress. Weekends are a good time to run these tests because it’s usually less disruptive to Development. Performance tests also require a real-world environment, preferably with a customer-like setup. This is crucial for getting good insight in the actual behavior of the system.


Avoiding these four common mistakes will drastically improve the outcome of your Continuous Delivery initiative. To recap:

  1. Delivering software is not just about Development and its build cycles—teams need to optimize the complete delivery pipeline.
  2. Fast feedback cycles are vitally important to have in place, so your team can find problems early in the cycle before they propagate and while they are cheaper to fix.
  3. Focus on the delivery of value to customers time after time. This approach requires teams to create a pipeline that is focused on the business benefit, not just the technology.
  4. Put an extensive nightly build and test cycle in place; it will help you continuously improve the quality of your software and learn what matters for customers, and what doesn’t.

In the end, it’s delivering value to customers… and collecting revenue from it… that really matter.

I’ve posted this article originally at blog.xebialabs.com.

Hoe je van een “acceptance phase” een “acceptance feest” kunt maken

Of ik het wilde horen of dat ik verkeerd stond afgesteld weet ik niet, een engineer had het onlangs over een acceptance feest. Nadat ik het verifieerde, bleek dat hij het over een “acceptance phase” had. Een periode na de sprint van de DevOps teams waar de acceptant aan de slag gaat. In die phase gebeurt er veel maar het wordt nooit een feestje. Waar gaat het mis?

Waarom die fase alle feestvreugde weghaalt

Hier een aantal redenen waarom het volledig mis gaat bij een acceptatie (test) fase van de software nadat je al klaar bent.
  • De acceptanten beginnen pas na te denken over wat ze willen nadat ze iets krijgen. Het gevolg is dat eindeloze aanpassingen nodig zijn in de volgende sprint.
  • Mensen die bij de demo de acceptatie hebben uitgevoerd, worden overschreeuwt door de mensen die werkelijk accepteren. Het mandaat en pikorde blijken totaal anders te lopen.
  • In de magere jaren waarin software van mindere kwaliteit werd opgeleverd, was een acceptatie test van dagen, zo niet weken, broodnodig om goede software naar productie te krijgen. Dit patroon is nog niet doorbroken.
  • Er is geen verbinding tussen wat in de sprint is gebeurd en wat daarna gebeurt tijdens de acceptatie testen. Dit heeft enorm veel dubbel werk tot gevolg.
  • Er ontbreken duidelijke acceptatie criteria waar naar toe gewerkt kan worden. Het programmeren wordt daarmee bijna een “wild guess”.

Een dubbele domper

Je snapt wel hoeveel frustratie dit bij de engineers oplevert. Deze frustratie is echter geheel wederzijds.
Opmerkingen van de acceptant zoals de volgende zullen met grote regelmaat zijn uitgesproken.
  • Ze snappen me toch niet,
  • krijg ik weer niet wat ik echt nodig heb,
  • waarom heeft dit zolang moeten duren,
  • hoe kan het toch dat ik elke keer weer moet aangeven wat ik echt wil hebben,
  • waarschijnlijk zullen er toch wel weer fouten inzitten.

Suggesties ter verbetering om er een feestje van te maken

Het is eigenlijk vrij eenvoudig om er een acceptatie feest van te maken. Daarbij moet je de fase achteraf wel durven los te laten. Hier een paar kleine suggesties om er een feestje van te maken.
  • Werk aan een wederzijdse overtuiging en drive om het daadwerkelijk anders en beter te gaan doen. Dit is van groot belang om een mini transformatie als deze door te maken.
  • Plaats de acceptant in het team zodat hij kan werken aan de acceptatie criteria voor de user stories in de volgende sprint.
  • Gebruik een testing tool als Concordion of een framework als Cucumber om de Acceptance Test Driven Development mogelijk te maken.
  • Doe de acceptatie tijdens de demo aan het einde van de sprint en daarmee en daarna gewoon door productie. De kwaliteit is goed en afwijkingen detecteer je met monitoring.
  • Creëer een continue groter wordende set aan automatische regressietesten op alle niveaus, van unit testen tot en met GUI testen.

7 suggesties voor een schaalbare continuous delivery pipeline

Een Continuous Delivery Pipeline als onderdeel van een Agile transformatie is gelijk aan de kruiden in een smaakvol gerecht. Bij ontbreken er van is het waardeloos en smaakt het naar niets. Is het aanwezig dan smaakt het naar meer, werkt het als stimulans en geeft het energie. Het is echter niet eenvoudig om de juiste kruiden bij het juiste gerecht te vinden.

Een basis van peper en zout is er nagenoeg altijd echter kun je niet altijd kurkuma, steranijs, gember of koriander inzetten om de boost te geven. Je moet met zorg een combinatie selecteren om je gerecht echt smaakvol te maken. Zo is het ook bij de tools die je onderdeel wilt maken van je continuous delivery pipeline.

Een continuous delivery pipeline is niet zomaar iets, het kan geen verzameling van tools zijn zoals de kruidenla in je keuken. Afhankelijk van de doelen die een team heeft kies je bepaalde tools wel en niet. In deze post deel ik 7 suggesties met je om een echte chef te worden.

  1. Voorkom de creatie van een monoliet
  2. Balanceer tussen verplichte en vrijwillige componenten
  3. Benader een CD pipeline niet als een verzameling tech tools maar als een value stream
  4. Gebruik de MVP approach in de opbouw van je pipeline
  5. Omarm een model waarin experimenten eenvoudig te realiseren zijn
  6. Limiteer het bouwen van eigen oplossingen, er is zo veel goeds op de markt
  7. Richt je CD pipeline in alsof het de meest kritische software is

Suggestie 1: Voorkom de creatie van een monoliet

Applicaties als monolieten zijn mogelijk ergens achterin je IT landschap nog best wel hanteerbaar. Hoe meer je naar de voorkant gaat en interactie zoekt met je klanten hoe meer last je krijgt van die grote monolieten in je landschap. Ze kunnen je wendbaarheid soms lastig in de weg zitten.

Ga je aan de slag met het maken van een CD pipeline bedenk dan goed dat deze pipeline misschien wel DE omgeving is die het hardste gaat veranderen in de komende tijd. Tools komen en gaan, frameworks dwingen je om je aan te passen en compliancy zit niet alleen meer bij een afdeling maar is als zuurstof voor je organisatie geworden. Een monoliet is maar weinig wendbaar weten we uit het verleden. Voorkom dus de creatie van een CD Pipeline als monoliet.

Continue reading

3 Belangrijkste ingrediënten voor Continuous Compliance

Het is al weer even geleden dat ik 5 redenen voor Continuous Compliance deelde, en de introductie gaf op dit onderwerp. Het jaar is inmiddels 8 maanden verder en zo ook de visie en inrichting van dit onderwerp.

In dit blog delen we met veel plezier de 3 belangrijkste ingrediënten voor Continuous Compliance.

  1. Maak gebruik van Build Breakers in de pipeline
  2. Zorg voor een goede segregatie van rechten
  3. Zet monitoring bovenop je pipeline

Een eerlijke onthulling

Persoonlijk ben ik het met nummer 1 volledig eens, nummer 2 en 3 vindt ik wat over de top. Ben je echter werkzaam binnen een omgeving waar Sox, audits en compliancy behoren tot de woordenschat van je bedrijf dan zul je er niet aan ontkomen om ze op te zetten. Als je dat doet, doe het dan goed en zo veel als mogelijk geautomatiseerd. Het ultieme doel is dat je er nauwelijks het omkijken naar hebt.

Maak gebruik van Build Breakers in de pipeline

Dit is echt een van de belangrijkste componenten om een veilige pipeline te hebben. Maar niet alleen veilige maar ook een pipeline die kwalitatief hoogwaardige software moet opleveren. Build Breakers zijn punten in je pipeline die ervoor zorgen dat de software niet wordt neergezet op omgevingen (Test en Acceptatie) verder in je pipeline als je niet voldoet aan bepaalde kwaliteitscriteria.

Door op deze manier te werken is er een garantie dat alles wat naar productie gaat ook daadwerkelijk de testen heeft doorstaan. Voor de auditors is dit echt een cruciaal punt. Deze manier van werken heeft twee grote bijkomende voordelen, de beslissing of iets naar productie kan gaan is in verre mate te automatiseren en het levert enorm snelle feedback cycles op voor iedereen in het proces.

4 Voorbeelden van build breakers:

  • Elke rode of oranje bevinding uit je static secure code analysis (op te zetten met Fortify SCA)
  • Een code coverage onder bijvoorbeeld 85% (op te zetten met SonarQube)
  • Een (API) regressie test die faalt (op te zetten met bijvoorbeeld Concordian)
  • Een performance daling van een stuk functionaliteit (op te zetten in Gatling)

Zorg voor een goede segregatie van rechten in je pipeline

Dit deel is eenvoudig en vanzelfsprekend. Een goede segregatie van rechten is een een hoog gereguleerde omgeving van cruciaal belang. Het komt er kortweg op neer dat je pipeline moet kunnen aantonen dat de persoon die de code maakt of aanpast niet de persoon is die de release naar productie kan aanzetten.

Continue reading

Continuous Delivery heeft een eco-systeem nodig om echt te slagen + video

Om daadwerkelijk succesvol te zijn met Continuous Delivery zijn tools alleen niet voldoende. Een eco-systeem daar omheen van feedback, versimpeling en flow zijn cruciaal om tot “Continuous Delivery of Value” te komen.
Het grootste doel is streven naar het voortdurend leveren van waarde de tools zijn daarbij van ondergeschikt belang. Twee weken geleden mocht ik dit verhaal presenteren. De volledige video met daarin de slides vind je in deze post.

4 belangrijke elementen van het eco-systeem rondom de continuous delivery pipeline

Het gaat niet om de tools, of het hebben van een hele snelle en volledig automatische pipeline. Hoe gaaf dat misschien ook is voor een DevOps team, het gaat om het creëren van waarde. Om tot waarde creatie te komen moet er meer gebeuren dan alleen je tools inrichten.
De volgende 4 elementen zijn van belang:
– Voortdurende feedback op alle lagen in je organisatie
– Constante versimpeling van je applicatie landschap en applicaties zelf
– Iteratieve groei van je pipeline; daar waar het waarde toevoegt
– Duidelijke visualisatie van je pipeline die leidt tot optimalisatie

Continue reading