One way to tackle that is to define and follow good life cycle policies.

What is a life cycle policy

A life cycle policy is a set of guidelines, written documents, describing the different steps in a product’s life, including its end of life.

Why you should have a life cycle policy

When you read the news, it is not uncommon to hear from here and there that company XYZ got hacked through an old software, outdated for ages.

Having a good life cycle policy guarantees you never have to deal with outdated software. It defines when you must upgrade your software and when you must stop using an old version and migrate to a new one.

Benefits are multiple:

• You don’t have to rely on unmaintained software
• You reduce attack perimeter, as newer versions have security patches applied
• You benefit from new versions’ features, allowing you to accelerate innovation

Of course there are downsides. The biggest one is having to stick with it. A life cycle policy is a written document and as such has value only if people read it and apply its recommendations.

Why you should automate it

A wise man once told “A good sysadmin is a sysadmin doing nothing”. Not because he is lazy, nor because he is bad at his job and got his credentials revoked, but because he automates all painful tasks, to focus on tasks with added value.

It also removes one major cause of errors: the human factor. An automated job will never mistype a command line or click on the `destroy` button, instead of the `upgrade` one.

Last but not least, it is a good way to make sure your carefully crafted document is not redirected to `/dev/null` in the following months.

Bonus: you also free a lot of time to automate new things !

How we did it

Our policy on cloud databases (available here: https://docs.ovh.com/gb/en/clouddb/managed-db-life-cycle-policy/) forces us to warn our customers at least 30 days before a major upgrade by e-mail. This email contains the day the upgrade will take place on.
We also have an internal mechanism allowing our customers to upgrade by themselves, using our API.
Combining these two bricks were all we had to do, with minor adjustments:

• When sending a email, we keep track of the planned date of the operation.
• An automated job is triggered every day, checking what operations are due this day and launching them.

Almost everyday, our job realises there is no major upgrade planned and goes back to sleep. But if a single operation is found, this job calls our API, triggering this upgrade. No human needed.

This process is very simple, yet very effective. We already had all the building blocks ready, from sending an email to API calls for major upgrades. All we had to do was to link all these operations together in a nice workflow. This allow us a very fine tuning of how many operation we want being done everyday, down to the instance.

Want to try the process for the first time ? Easy, trigger it on one of our test instance.
Is this process reliable and scalable ? Enough to upgrade a batch of 10 000 instances in 30 days with no human intervention !

One last word on an automated life-cycle policy

At Web Cloud Databases, with thousands of instances, 4 different DBMS and a total of 12 major versions, automation is the key.

In May 2021, for this process’ firsts steps in this world, we upgraded 6K instances in a week. The only human interaction needed was to launch a script to inform all affected customers.

Figures of this use-case ? 6000+ instances updated, 0 website down, 1 human needed for 5 minutes.

Before delving into a full explanation of CDS workflows, let’s review some of the key concepts behind pipelines and jobs. Those concepts are drawn from the reference book, 8 Principles of Continuous Delivery

The basic element: “The job” 

A job is composed of steps, which will be run sequentially. A job is executed in a dedicated workspace (i.e. filesystem). A new workspace is assigned for each new run of a job.

A standard build job looks like this: 

You can use “built-in” actions, such as checkoutApplication, script, jUnit, artifact upload/download.

• The checkoutApplication action clones your Git repository
• The Script action executes your build command as “make build”
• The artifactUpload action uploads previously-built binaries
• The jUnit action parses a given Junit-formatted XML file to extract its test results

A pipeline: How to orchestrate your jobs with stages

With CDS, a pipeline is not a job flow. A pipeline is a sequence of stages, each of which contains one or more jobs.

A  Stage  is a set of jobs that will be run in parallel. Stages are executed sequentially, if the previous stage is successful. 

Let’s take a real-life use case: the pipeline that built CDS. This pipeline has four stages: 

• The “Build Minimal” stage is launched for all Git branches. The main goal of this stage is to compile the Linux version of CDS binaries. 
• The “Build other os/arch” stage is only launched on the master branch. This stage compiles all  binaries supported by the os/arch: linux, openbsd, freebsd, darwin, windows – 386, amd64 and arm.  
• The “Package” stage is launched for all Git branches. This stage prepares the docker image and Debian package.
• Finally, the “Publish” stage is launched, whatever the Git branch. 

Most tasks are executed in parallel, whenever possible. This results in very fast feedback, so we will quickly know if the compilation is OK or not. 

CDS Workflows: How to orchestrate your pipelines

The workflow concept is a key feature, and widely considered a native, manageable and feature-rich entity in CDS. A CDS Workflow allows you to chain pipelines with manual or automatic gates, using conditional branching. A workflow can be stored as code, designed on CDS UI, or both, depending on what best suits you. 

Let’s take an example. One workflow for building and deploying three micro-services:  

• Build each micro-service 
• Deploy them in preproduction 
• Run integration tests on preproduction environment 
• Deploy them in production, then re-run integration tests in production

For the building part, there is only one pipeline to manage, which is used three times in the workflow with a different application/environment context each time. This is called the “pipeline context”. 

Any conditional branching against the workflow (e.g.“automatic deployment on the staging environment, only if the current Git branch is master”) can be executed through a “run conditional” set on the pipeline. 

Let’s look at a  a real use case. This is the workflow that builds, tests and deploys CDS in production at OVH (yes, CDS builds and deploys itself!):

1. For each Git commit, the workflow is triggered 
2. The UI is packaged, all binaries are prepared, and the docker images are built. The “UT” job launches the unit tests. The job “IT” job installs CDS in an ephemeral environment and launches the integration tests on it. Part 2 is automatically triggered on all Git commits.  
3. Part 3 deploys CDS on our preproduction environment, then launches the integration tests on it. It is started automatically when the current branch is the master branch. 
4. Last but not least, part 4 deploys CDS on our production environment. 

If there is a failure on a pipeline, it may look like this:

The same kind of workflow is used for building and deploying the Prescience Project (https://labs.ovh.com/machine-learning-platform):

But of course, you’re not limited to the most complex tasks with CDS Workflows! These two examples demonstrate the fact that workflows allow to build and deploy a coherent set of micro-services. If you have simpler needs, your workflows are, of course, simpler.

Pipeline reusability allows you to easily maintain the technical parts of the build, tests and deployments, even if you have hundreds of applications. If hundreds of applications share the same kind of workflows, you can leverage the maintainability of the workflow templates. We will talk more about this in a future post.

Much more than “Pipeline as Code”… “Workflow as Code”

There is no compromise with CDS. Some users prefer to draw the workflows by the web UI, others prefer to write yaml code. CDS lets you do both! 

There are two ways to store workflows: either in the CDS database or on your Git repository with your source code. We call this “Workflow as Code”.

This makes it possible to have a workflow on a given branch, and then develop it on another branch. CDS will instantiate the workflow on the fly, based on the yaml code present on the current branch.

CDS is OVH open-source software, and can be found on https://github.com/ovh/cds, with documentation on https://ovh.github.io/cds. 

Previous Posts: 

• CDS Introduction: https://www.ovh.com/fr/blog/how-does-ovh-manage-the-ci-cd-at-scale/  
• DataBuzzWord Podcast (French): https://www.ovh.com/fr/blog/understanding-ci-cd-for-big-data-and-machine-learning/   

The Continuous Delivery Team at OVH has one fundamental mission: to help the OVH developers industrialise and automate their delivery processes. The CD team is here to advocate CI/CD best practices and maintain our ecosystem tools, with the maximum focus on as-a-service solutions.

The centre of this ecosystem is a tool called CDS, developed in-house at OVH.
CDS is an open-source software solution that can be found at https://github.com/ovh/cds, with documentation at https://ovh.github.io/cds.

CDS is the third generation of CI/CD tools at OVH, following two previous solutions, that were based on Bash, Jenkins, Gitlab and Bamboo. It is the end-result of 12 years’ experience in the field of CI/CD. Familiar with most of the standard tools of the industry, we found that none completely matched our expectations regarding the four key aspects we identified. That is what CDS tries to solve.

These four aspects are:

Elastic

CDS resources/workers are launched on demand, to guarantee low waiting times for users, with no over-consumption of idle resources.

Extensible

In CDS, any kind of action (Kubernetes and OpenStack deployments, pushing to Kafka, testing for CVEs…) can be captured in high-level plugins, to be used as building blocks by users. These plugins are straightforward to write and use, so it’s easy to meet the most exotic needs in an effective and stress-free way.

Flexible, but easy

CDS can run complex workflows, with all sorts of intermediary steps, including build, test, deploy 1/10/100, manual or automatic gates, rollback, conditional branches… These workflows can be stored as code in the git repository. CDS provides basic workflow templates for the Core team’s most common scenarios, in order to ease the adoption process. This way, building a functional CI/CD chain from nothing can be quick and easy.

Self-service

Finally, a key aspect is the idea of self-service. Once a CDS project is created by users, they are completely autonomous within that space, with the freedom to manage pipelines, delegate access rights etc. All users are free to customise their space as they see fit, and build on what is provided out-of-the-box. Personalising workflow templates, plugins, running build and tests on custom VM flavors or custom hardware… all this can be done without any intervention from the CDS administrators.

CI/CD in 2018 – Five million workers!

• About 5.7M workers started and deleted on demand.
• 3.7M containers
• 2M Virtual Machines

How is it possible?

One of the initial CDS objectives at OVH was to build and deploy 150 applications as a container in less than seven minutes. This has been a reality since 2015. So what’s the secret? Auto-Scale on Demand!

With this approach, you can have hundreds of worker models that CDS will launch via hatcheries whenever necessary.

A hatchery is like an incubator: it gives birth to the CDS workers and maintains the power of life and death over them.

Each hatchery is dedicated to an orchestrator. Furthermore, one CDS Instance can create workers over many cloud platforms:
– The Kubernetes hatchery starts workers in pods
– The OpenStack hatchery starts virtual machines
– The Swarm hatchery starts docker containers
– The Marathon hatchery starts docker containers
– The VSphere hatchery start virtual machines
– The local hatchery starts process on a host

What’s next?

This is all just a preview of CDS… we have lots more to tell you about! The CI/CD tool offers a wide range of features that we will explore in depth in our upcoming articles. We promise, before 2019 is done, you will not look at your CI/CD tool the same way again…

Pourquoi ce projet de création d’un nouveau site pour les équipes Manufacturing et Logistique ?

G. H. Étant donné l’hypercroissance d’OVH, il fallait que nous puissions disposer d’un nouveau site de production pour l’Europe, en plus de Beauharnois au Canada et du projet d’ouverture d’une chaîne de production aux États-Unis. Le seuil actuel de capacité de production à l’année va ainsi passer de 120 000 à 400 000 serveurs. Mais plus qu’une nouvelle unité, nous voulions en profiter pour en faire une usine world class basée sur le lean management. Il s’agit d’un principe sur lequel je m’appuie depuis de nombreuses années déjà et qui a fait ses preuves dans des secteurs aussi exigeants que celui du nucléaire. J’ai acquis une expertise en lean management pendant mes 15 années dans le secteur industriel, de la robinetterie au gaz en passant par le nucléaire. J’en connais la valeur. Je n’étais pas spécialiste en informatique, mais je me retrouvais bien dans l’état d’esprit qu’Octave Klaba a su insuffler à OVH. Ici, tout est malin et catalyseur d’idées, très propice au lean. Cette approche permet en effet de concilier amélioration des performances de l’entreprise, notamment le niveau du « juste-à-temps », avec l’implication des employés dans l’amélioration et la conception de leurs environnements de travail. C’est ce qui a guidé ce projet de site à Croix.

Qu’entendez-vous par « usine world class » ?

G. H. Le site de Roubaix était pragmatique et performant. Il a évolué au fil de la croissance de l’entreprise quasi exclusivement dans une logique d’efficacité. Nous avons besoin d’augmenter notre capacité de production, et également de bénéficier des technologies et méthodes de production les plus récentes. Par exemple, aucun soin particulier n’avait jusqu’à présent été apporté pour que la chaîne d’assemblage soit valorisable aux yeux des clients. Aujourd’hui, nous avons besoin de pouvoir leur montrer ce que nous sommes capables de faire. Le site de Croix a ainsi été prévu pour être une véritable vitrine industrielle pour nos partenaires et nos clients. L’idée est de leur donner confiance dans notre chaîne logistique et notre organisation industrielle pour qu’ils soient convaincus de choisir le bon partenaire. Le site de Croix va permettre de démontrer à chaque instant que la maîtrise des processus industriels représente un avantage compétitif de qualité, coût, délai et flexibilité.

Comment tout ça va se concrétiser ?

G. H. L’amélioration de la productivité et le développement de l’agilité doivent avant tout servir l’humain. Par exemple, la pose d’une résine au sol pour éviter toute vibration et donc permettre le transport des pièces par des robots, représente une opportunité pour les salariés de réduire la pénibilité, de se concentrer sur des tâches à plus forte valeur ajoutée tout en bénéficiant d’un environnement de travail amélioré. C’est ça aussi, l’entreprise 4.0 ! En fait, nous souhaitons vraiment que les équipes Manufacturing et Logistique puissent s’exprimer dans toute leur ingéniosité et créativité. Avec à la mise à disposition des données numériques, la robotique avancée et l’automatisation, les salariés vont pouvoir monter en compétence sur la proactivité, la prise de décision rapide ou les ajustements en temps réel. Le management a ainsi été rendu plus visuel pour qu’en un coup d’œil, les anomalies éventuelles soient apparentes et que les collaborateurs puissent réagir en conséquence, dans les plus brefs délais.

Et c’est là aussi où le lean management joue un rôle majeur ?

G. H. Sous l’angle du lean management, tout l’environnement a du sens. Cela passe notamment par la réduction du lead time, c’est-à-dire la mise sous contrôle des encours de production, des niveaux de stock et de la vitesse de défilement dans les opérations. Nous avons aussi travaillé sur la préparation en bord de ligne pour que les différents composants soient disponibles et prêts à être assemblés au moment opportun, comme dans le secteur automobile. Avec plus d’une centaine de combinaisons possibles de ses serveurs, OVH a vraiment besoin d’agilité et de flexibilité pour assurer la personnalisation des machines. C’est toute l’ambition du concept de One Piece Flow que nous avons aussi mis en place. Nous devons vraiment être performants entre l’arrivée des composants et la sortie finale du produit. Ce flux tendu permet de produire 95 % des serveurs en moins de 4 jours.

Comment vont être organisés les espaces disponibles ?

G. H. Les 14 000 m2 de ce nouveau site doivent permettre d’intégrer la centaine de personnes des équipes opérationnelles de Manufacturing et Logistique, ainsi que leurs unités de production. Avec la logique du lean management, nous avons souhaité optimiser l’espace disponible pour pouvoir disposer de capacités de développement futur, mais aussi accueillir certains prestataires. OVH a en effet choisi de se focaliser sur son cœur de business, l’intégration des éléments techniques et informatiques. La fabrication de certains composants, notamment les activités de laser, soudure et d’usinage des métaux, est confiée à des prestataires de confiance. Ils s’installeront dans le bâtiment pour améliorer les lead times, mais aussi pour gagner en flexibilité entre nos labos et nos protos.

Des laboratoires seront aussi présents ?

G. H. L’innovation doit être permanente et le site de Croix permettra de concentrer les équipes, les espaces et les conditions pour améliorer notre vitesse d’innovation et notre processus de développement de nouveaux produits. Cinq laboratoires ont ainsi été prévus : le labo hardware, dédié à la performance des composants et du serveur assemblé, le labo soft pour la vérification de l’intégration dans le système informatique et la mise à jour logicielle sur l’intégralité du parc, le labo clim consacré au fonctionnement des serveurs dans des conditions extrêmes de températures, le mini datacenter pour tester les différentes solutions mécaniques, thermiques et structurelles et le labo industrialisation prévu pour le développement des nouveaux produits et ouvert à l’innovation participative.

Pourquoi avoir choisi le site de Croix ?

G. H. Le choix d’une ville située à quelques kilomètres des datacenters de Roubaix est bien sûr stratégique pour optimiser les approvisionnements. Cela permet également aux salariés de ne pas trop bousculer leurs habitudes de vie. Le site est d’ailleurs bien desservi en transports en commun. Ce bâtiment industriel de type cathédrale présente aussi des volumes intéressants avec une grande hauteur sous plafond, des murs droits et des sols lisses. La lumière a également été revue pour atteindre les 500 lux et permettre de travailler dans un environnement de qualité. Enfin, toute la capacité énergétique était déjà présente, du fait de l’activité précédente.

Quand sera-t-il opérationnel ?

G. H. Le site est destiné à devenir le quartier général de l’activité Industry d’OVH. Il sera divisé en deux parties : la logistique et la production. Je tiens d’ailleurs à saluer toutes les équipes qui se sont montrées tout à fait ouvertes au changement, qui ont fait preuve d’agilité et qui se sont énormément impliquées pour que tout soit prêt en temps et en heure. Je précise aussi qu’en attendant la fin du déménagement, prévu pour septembre, l’usine de Roubaix reste entièrement opérationnelle pour assurer toutes les commandes.