Continuous deployment

 

A web application and a mobile application are immediately available to your users. All they need is a URL to access the latest version. This is a paradigm shift that has overturned old operating habits which required a time window in which to prepare a product that had to be “finished”. A corresponding example is that of the physical newspaper. Nevertheless, this is a working method that remains embedded in our organisations.

You can update your digital applications as soon as you need to. This greatly reduces the timescale in which it is possible to offer new services to your customers. It is even possible to test for commercial interest in a new service before it is fully finished.

And yet there are obstacles, particularly from a technical point of view:

• How do you ensure that a roll-out is not a leap into the unknown?
• What’s stopping you from putting new developments into production on a Friday?
• Why does it take weeks for a spelling mistake to be corrected in production?

What tools and practices are needed to put in place an effective practice of continuous adaptation?

1 How do you manage your code?

1.1 Parallelise and prioritise

Code management tools such as Git allow you to work more serenely as a team because everything is centralised in one place. Yet this is just one of the benefits of these tools. The branching system means that a new feature can only be merged once it has been completed. Each feature must therefore be developed independently of the others, and the order in which they are made available depends on your priorities and their availability.

1.2 Automating a first level of qualification

IT development is a science with a long history that provides it with a vast knowledge base. Standards exist, and there is no reason not to use them. What’s more, development tools can themselves apply modifications to existing code to comply with these standards. If this is not possible, they can alert you to the problems identified. Even if the standards are not perfect, doing without this first level of help risks errors once in production.

1.3 Re-reading code is also a way of making progress

Even if the automation of development tools is progressing on a regular basis, we cannot recommend highly enough that a peer review is carried out. The aim is to validate that the resources that have been put in place correspond to what was defined, with development methods that are consistent with the knowledge and habits of the rest of the team. In this way, you ensure that the code evolves in such a way that it is not too costly to maintain. Another member of the team will be able to do the same. And at the same time this is what helps another person who is still in a learning phase to improve their skills.

1.4 Artificial intelligence, a new form of assistance

Code-writing tools have undergone a technological revolution that means they can now be used as programming aids. AI tools take into account the context of what you are writing to make time-saving suggestions. While you shouldn’t trust them blindly, it’s also not a good idea to ignore them completely.

2 How can automated quality analysis be integrated?

2.1 Continuous integration

Before joining to the main code base, all new code can go through several qualification phases. These tests are automated. No manual action needs to be taken to ensure that they are always executed. You can then choose what happens if the target standards are not met. You can be satisfied with an alert, or block the merging of new code.

2.2 Executing unit tests

The purpose of unit testing is to ensure that a change in the code is not regressed. The tests are often quite remote from the functional aspect of your solution. In fact, their aim is to test atomic elements that manage only part of a whole function. Nevertheless, if they fail, the entire functionality is impacted. So when an evolution has to be merged, we need to ensure that these tests are always respected. This method greatly reduces the risk of regression.

2.3 Code quality analysis tools

A code base can quickly become very large, with hundreds of thousands of lines of code. Such a volume is not compatible with a manual review. This is why it is advisable to use tools that will carry out a review exercise, highlighting faults in relation to the knowledge bases on the languages used. For example, these tools will measure:

• bits of code that are present several times, which complicates maintenance and correction (it has to be done several times),
• complexity, which has a negative impact on maintenance work by someone who did not write the code in the first place,
• poor security practices, which can end up in the production code.

These tools conserve the history of changes in indicators. This is important in order to know whether the risks associated with production releases are increasing over time. Investing in upgrade work becomes more natural when you know why you’re doing it and when you can measure that the objective has been achieved.

3. Why and how should automated tests be set up?

3.1 APIs

The web application ecosystem relies on APIs, which are critical to the smooth operation of your services. If you are responsible for APIs, you are obliged to maintain a high level of quality in order to not impact on the smooth running of the applications that depend on them. Even if you have already set up unit tests to limit the risk of unforeseen changes, we also advise that you set up automated tests that will use your APIs and ensure that scenarios representative of their use remain functional. This extra layer of assurance will improve your quality.

3.2 The user interface

It is possible to programmatically control a web browser or a mobile phone, and have it execute a scenario that it can reproduce on demand. It will behave like a user, i.e. use all the graphical elements that enable interaction with the application (fill in a form, manipulate elements with the mouse or finger, etc.).

In general, these tests cannot be exhaustive because they take a long time to run and are time-consuming to write. Nevertheless, it is always possible to test critical paths with a moderate effort. They then have a very high added value. If they run well, the risk of a deployment causes a break in service becomes minimal.

3.3 Conditions for reproducibility

To be able to run automated tests, you need to be able to provide them with an environment in which they can always run the same test. If we take the example of an ecommerce site, certain products must always be available, or even always on sale. There are several strategies for achieving this:

• modifying the reference database
• modifying the behaviour of the APIs used
• enabling the test interface to avoid blocking points (such as the captcha, for example).

4 How do you set up automated deployments?

4.1 Script the entire production deployment process

Deploying code in production is a series of operations which must be carried out according to a very precise schedule and commands. Mistakes must be avoided because the impact is almost always a loss of service. When the operation is manual, it can also be time-consuming, making a person, who must also have very specific knowledge, unavailable for other tasks.

For these reasons, it is preferable to automate all these stages, which not only ensures that they are always reproduced in the same way, but also that they stop as soon as a malfunction is detected.

Finally, it will no longer be necessary to call in a dedicated technician for each deployment.

4.2 Controlling rollback

As there is never a zero risk of error, it is necessary to anticipate a reaction in the event of a problem. The most traditional response is to equip yourself for a rollback if the correction takes too long. As with deployment, if it is automated, you are equipped to limit the impact of a poor production launch.

4.3 Gradual release to the public

A web or mobile application can be made available to users at a controlled pace. It is not necessary to open it up to everyone at the same time. It can be done in two stages, for example, with 50% of users having access to the new functions while the rest continue to have access to the old version. The deployment process needs to take this into account. Even after all the tests have been carried out, if it’s during deployment that you realise there’s a problem, you can fix it right from the start, while there are still only a few people with access to it. This limits the impact on the customer.

5 What monitoring and alert tools should be put in place?

5.1 Observability

Are your tests sufficient to ensure that the application works correctly for everyone? It’s impossible to answer this question without observing everything that happens in your environment. Tools for analysing user behaviour (such as Google Analytics) can provide a partial answer to this problem, but their main shortcomings are that they are not real-time, and, above all, that they are not equipped to provide alerts by default.

5.2 Open Source tools

To monitor your applications, you can put in place tools that will retrieve all the traces generated by your servers, aggregate them in a centralised location, and finally allow you to view them. Predesigned dashboards can also be set up for the software bricks that set the benchmark. The Open Source community makes many of these available. Finally, they allow you to set up alert systems, which can be emails, instant messaging tools or incident management platforms. In this way, you’ll be alerted even before you see the impact on your visitors in your analytics tool.

5.3 APM (APplication Monitoring)

In addition to Open Source tools, there are a number of solutions that simplify the implementation of global observability, and above all enable you to benefit from automatic alerts. Using statistical tools, these solutions can identify behaviour that deviates from what is generally observed, and if these deviations have a negative impact on your users (such as a deterioration in response times), you can be alerted without having to carry out any configuration.

6 What are the business benefits of continuous deployment?

6.1 Reactivity

In a digital ecosystem where competition is fierce, being able to react quickly is an important aspect of your business. If your service does not offer a satisfactory experience, it only takes one click to go to a competitor. That’s why it’s advisable to choose an approach that allows you to quickly deploy an improvement that will benefit your business.

6.2 Controlling investment

Do you know how to deploy changes to your business quickly and with peace of mind? In this way you can test developments that are incomplete in relation to your target vision, but which are already adding value. And, depending on how they are received and used, you can adapt your strategy to take account of what you’ve learned. Your investments are therefore more profitable because you avoid work that will not be taken onboard by its intended audience.

In conclusion

Continuous adaptation means firstly being able to put any solution increment into production as soon as it is ready. Secondly, it must be possible to go into production with as little risk as possible when making changes to a platform that has worked well up to now. And thirdly, if a problem does arise, we need to be warned so that we can react.

These are the three pillars on which Kaliop has built up its experience and expertise. We rely on them in the projects we undertake. We can help you implement them in your organisation.