Continuous deployment results in a higher sense of responsibility and better quality of deployments, argues Paul de Raaij, technical pathfinder at Coolblue. Coding standards prevent your code base from becoming a mess, automated inspections are great for tedious and boring checks, and manual checks are great for checking if the logic or use of code actually makes sense.
De Raaij wrote the blog post continuous deployment of our software in which he described how deployment is done at Coolblue:
Just developing software is not enough. You’ll need to get it on production and you want to be sure that you deploy quality software and not breaking software.
Paul de Raaij will talk about Continuous Deployment at Coolblue at the Agile and Software Architecture Symposium 2016. InfoQ interviewed him about deployment at Coolblue, the advantages and pitfalls of continuous delivery, techniques and practices for quality assurance, coding standards, monitoring applications, and the challenges that Coolblue is facing and how they will deal with them.
InfoQ: What made Coolblue decide to make it possible for developers to do their own deployment?
Paul de Raaij: We want to get our software in production as soon as possible. This helps us to quickly get feedback on the functionalities that we create and use that feedback to learn and diverge if necessary. We are also fond on development teams having full ownership of their products. Instantiating release engineers for example is shifting responsibilities that are key to having full ownership. If you break it, you are the one that has to fix it. Not someone else that gets the troubles shifted in their shoes. It results in a higher sense of responsibility and better quality of deployments.
InfoQ: How is deployment currently done?
De Raaij: It’s hard to give a short and comprehensive answer on this, but this is the short outline: we use GIT as a distributed versioning system utilizing the gitflow workflow. When a developer wants to put his new code live, he creates a pull request. This pull request will be automatically and manually reviewed. All lights on green? Automatically the software will be packaged and put on development and acceptance test severs. A manually press on the button will push the deployment to production. Of course there are many bits in between which I’ll talk more about in the session at ASAS.
InfoQ: What are the advantages of continuous delivery?
De Raaij: It offers multiple advantages. For starters, if done right it proves that you are able to deploy your software to a server. It displays a certain level of quality as this is automatically inspected by the various inspection tools. If regression tests are properly set you can be safe that old functionality still works after your deployment.
InfoQ: Any pitfalls?
De Raaij: In the end it still is a manual process that is configured by people. It is easy to ensure the happy path but things still can go wrong. So a lot of thought has to go in your configuration of the CI process. For example, if you make use of online services and they break down (e.g. GitHub), how does this affect your process?
Also think about the size of your development team. Your CI pipeline might have to work differently when 500 developers work on the same process, than when only a couple of people do updates. So, think upfront about how scalable your solution has to be. Is it easy enough to add additional agents for code inspection? Is it okay to wait half an hour before a pull request is inspected, or not?
InfoQ: Which techniques and practices does Coolblue use for quality assurance, and why?
De Raaij: We make use of various methods and they also vary in manual and automated inspections. Automated inspections are great for tedious and boring checks such as linting, checking code standards, executing regression tests. The manual checks are great for checking if the logic or use of code actually makes sense. If what has been programmed actually solves the full use case.
InfoQ: How are coding standards applied? Which benefits do they bring?
De Raaij: Coding standards are important in order to prevent your code base from becoming a mess. If every developer would have their own rules for indentation, spacing and naming it quickly will be a chaos. This will greatly affect the quality of software and deliverables and also make it hard to work for developers; frustration and irritation would grow rapidly.
In our case coding standards are mostly defined by industry standards. PHP for example mainly follows the standards set by PSR with some minor specific tweaks.
InfoQ: How do you monitor your applications?
De Raaij: Many tools play a part in our monitoring. For technical monitoring of machines we rely heavily on Nagios as our go-to monitoring application. This really focuses on the state of the machine and if applications and daemons are running. Monitoring is key in our software landscape, all our applications have their own metrics as well which we use for health checking, insights and analysis. These metrics are send to datadog via a StatsD like aggregator. Besides metrics, we heavily analyze our logs, making use of the ELK stack.
InfoQ: What are the challenges that Coolblue is facing, and how will you deal with them?
De Raaij: Full continuous delivery is a big item for us. We made quite some progress already, but there are obstacles in our path preventing us from having true automated deployments. A big obstacle is how to handle data migrations in our system which is hard in our application landscape. If we settle that issue, we are really close to having true continuous deployments.
The Agile and Software Architecture Symposium 2016 will be held on September 28 at the GelreDome in Arnhem, the Netherlands:
ASAS is a practical solutions driven conference, where technical leads, software architects, business analysts and engineering directors can learn about and discuss better ways to deliver the software solutions that are right for their users.
InfoQ will cover this conference with Q&As, summaries, and articles.