Today, we It is a set This These One of the But there We can therefore, without realizing it, and The best way to avoid this risk is to build the Now that we These At AT The passage We then Once these Each We will If everything is ok, then we can promote the In this Each time In In this If delivery Staging Some tests At this This The launch of certain tests on a given The ideal When one or At a higher Until the day when we can gladly realize that we Today, we are going to decode a visual. It represents the principle of continuous integration at AT Internet: \u201cContinuous integration at AT Internet\u201d The main principles of continuous integration It is a set of practices designed to effectively deliver the software code produced by development teams. There are various objectives, including: Limiting manual actions by […]<\/p>\n","protected":false},"author":1,"featured_media":79177,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12033],"tags":[11230,28699,39991,19852,14481],"dealstore":[],"offerexpiration":[],"class_list":["post-79176","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-analytics","tag-code","tag-continuous","tag-deliverables","tag-environments","tag-integration"],"yoast_head":"\n
\nare going to decode a visual. It represents the principle of continuous
\nintegration at AT Internet:<\/p>\n![\"Continuous](\"https:\/\/blog.atinternet.com\/wp-content\/uploads\/2019\/09\/Int\u00e9gr-1024x475.jpg\")
The main principles of continuous integration<\/h2>\n
\nof practices designed to effectively deliver the software code produced by
\ndevelopment teams. There are various objectives, including:<\/p>\n\n
\nmanual actions by automating builds, deliveries and other deployment operations.
\nThis limits the risk of human error and allows experts to focus on their
\nproduct rather than continually investing time in repetitive operations that a
\nmachine can do for them.<\/li>\n<\/ul>\n\n
\nrapid availability of feedback offering a good visibility on the potential
\nimpacts of changes made to the existing code. Each member of the development
\nteams can then calmly make changes to the existing code base and rely on the
\nautomation in place to inform them of the proper integration of their code into
\nthe product.<\/li>\n<\/ul>\n
\nconcerns the continuous integration of new code, continuous delivery of
\ndeliverables and continuous deployment of products \u2013 but how do you link source
\ncode, deliverables and environments in the overall process? Here are some of
\nthe FAQs:<\/p>\n\n
\nI practice \u201cpromotion\u201d, is it the promotion of my code? The promotion
\nof deliverables? The promotion of the environment?<\/li>\n
\nis the link between the deployment in production and the master branch of code
\nrepository?<\/li>\n
\nautomation can I implement to ensure consistency between the life of my code
\nrepository and that of my application, across different environments?<\/li>\n<\/ul>\n
\nquestions may be answered differently depending on the technical or project
\ncontext, the sector of activity or the level of maturity of the processes in
\nthe company. In this article, I will therefore try to describe the various concepts
\nand principles, without creating dependency on a particular tool. Even if some
\ntools can sometimes make life easier, it is more a question of the software
\ndelivery cycle, regardless of the means chosen for its implementation. <\/p>\nThe \u201cbuild once\u201d concept<\/h2>\n
![\"Build-once](\"https:\/\/blog.atinternet.com\/wp-content\/uploads\/2019\/09\/Build-once-Blog-1024x386.png\")
\nkey principles of continuous integration is \u201cbuild once\u201d or in other
\nwords, only build a new deliverable if the business code has been modified.
\nThis practice is intended to reduce the risk of building a different
\ndeliverable when deploying it in a new environment. Indeed, we find re-build
\npractices all too often when delivering, thinking of obtaining an identical
\ndeliverable.<\/p>\n
\nare still risks (sometimes significant) during this new build:<\/p>\n\n
\nother\u2026)<\/li>\n
\n(in maintenance, unavailable)<\/li>\n
\nthe dependencies of our product<\/li>\n
\nversion of the code<\/li>\n<\/ul>\n
\ndespite taking precautions, obtain a product different from the one that has
\nsuccessfully passed the various validation phases of our development cycle. All
\nthe benefits of the tests and verifications carried out are then lost. <\/p>\n
\ndeliverable only once and then use it as it is, during future deployments, for
\nthe validation phases and until final production \u2013 this is what is known as \u201cbuild
\nonce\u201d.<\/p>\nThe promotion of deliverables<\/h2>\n
![\"Promotion](\"https:\/\/blog.atinternet.com\/wp-content\/uploads\/2019\/09\/Livrables.png\")
\nhave our deliverable, we will want to subject it to a number of tests to be
\nable to validate its production launch. We therefore need different
\n\u201cshelves\u201d to store our deliverables in order to easily identify them
\naccording to their progress in the validation phases. <\/p>\n
\n\u201cshelves\u201d can take different forms depending on the technologies
\n(deliverable managers, delivery folders, archiving of artefacts, storage of
\ndocker images, etc.) and their number depends on the chosen delivery cycle.
\nSome companies will need more validation and integration phases than others,
\nfor reasons of compliance with certain standards, complex integrations etc.<\/p>\n
\nInternet, we have chosen to have 4 \u201cshelves\u201d to organize our
\ndeliverables (dev, integ, preprod, prod) and an additional one (staging) to
\nallow the urgent delivery of bugfixes.<\/p>\n
\nfrom one deliverable from one shelf to another is conditioned by the proper
\nconduct of different test and validation phases. If all the conditions are met,
\nthe deliverable can be moved to the next shelf: this is the promotion. Some
\nwill simply copy (rather than move); some tools directly expose methods for
\npromoting the deliverables they host.<\/p>\n
\nhave an overview of the deliverables and their level of validation, simply by
\nobserving their place in the repository. The presence of a deliverable on one
\nof the shelves also describes its character as a candidate for a given
\nenvironment. It is this strong link that sometimes leads to the term
\n\u201cenvironment promotion\u201d. <\/p>\nInternal environments<\/h2>\n
![\"Internal](\"https:\/\/blog.atinternet.com\/wp-content\/uploads\/2019\/09\/environnement-dev.png\")
\ndeliverables have been obtained and stored somewhere, they must undergo the
\nvarious testing and validation steps to decide whether or not we can deliver
\nthem to production. It is then necessary to deploy each deliverable on the
\nenvironment to which it is a candidate. It is the commissioning of the product,
\non a given environment, to perform dynamic tests. These tests are called
\n\u201cblack box\u201d tests, independent of the code or technology used for
\nimplementation. <\/p>\n Development: the first phase of deployment <\/h3>\n
\ndeliverable is then deployed on the development environment and subjected to a
\nfirst phase of testing. The first of these tests consists in validating the
\ndeployment mechanism. This is the first time we have tried to deploy this
\ndeliverable somewhere. The successful completion of the deployment is a first
\nstep to ensure that we are able to deliver the product to production.<\/p>\n
\nthen validate on this environment a number of properties of our system
\n(functional or non-functional) but also the validity of some configurations of
\nour deliverable. <\/p>\n
\ndeliverable and deploy it to the next environment for the integration phase.<\/p>\nIntegration: validate all scenarios<\/h3>\n
\nphase, the system validated in isolation is brought into contact with the other
\nsystems of the software solution. It can then be used in the system integration
\ntesting phase, which aims to carry out business use cases that cross several
\nsystems in order to validate the correct connection of the various elements of
\nthe solution.<\/p>\n
\nthe validation on the development environment is successful, this integration
\nenvironment can be updated.<\/p>\nPre-production: dress rehearsal<\/h3>\n
\npre-production, we carry out a final phase of tests before going into
\nproduction, deploying only those features that we decide to go into production
\nwith the next release. This decision is not a necessary step and is often
\nlinked to a marketing or commercial decision. <\/p>\n
\nenvironment, these are often receipt and acceptance operations, which are not
\nintended to detect bugs in the product. If bugs are found at this stage, it is
\noften a sign of a lack of testing in one of the previous steps.<\/p>\n
\nin production is not linked to customer communication or support constraints,
\nit is entirely possible to have only one \u201cpre-production\u201d
\nenvironment, instead of integration and pre-production environments. We then
\naccept the constraint (or advantage) that all the validated code goes straight
\ninto production if it successfully passes the following validation steps.<\/p>\nStaging<\/h3>\n
\nmakes it possible to validate a correction to be made quickly in production.
\nThe current production code will be deployed on this environment, with only the
\ncorrection made as a modification, in order to validate the correct correction
\nof the problem observed. The absence of side effects (regressions) of this
\nproduct modification is also checked.<\/p>\nProduction<\/h3>\n
\nof a different type can take place in production, often referred to as
\n\u201cPost-Deployment Tests\u201d. It is rather a question of validating
\naspects related to the environment, specific configurations, monitoring systems
\nor what I would call functional experiments (canary testing, A\/B testing,
\nfeature flipping) etc\u2026. <\/p>\n
\nstage, the objective is not to detect any bugs in one of the systems involved
\n(even if this can happen!)<\/p>\n Delivery automation <\/h2>\n
![\"Jenkins-delivery-automation\"](\"https:\/\/blog.atinternet.com\/wp-content\/uploads\/2019\/09\/Jenkins-optimisation-livraison.png\")
<\/figure>\n<\/div>\n
\norchestration of the delivery of a software product is intended to be
\nsystematic and repetitive. It is therefore normal to think about automating all
\nthis. Different tools are of course available to set up this orchestration
\n(Jenkins, Travis CI, GitlabCI etc\u2026) but the principles are independent of the
\nchoice of this tool. Beyond the essential steps of this automation (shown on
\nthe right on the image linked to the article), it seems important to me to
\nhighlight only a few details:<\/p>\n\n
\nthe deliverable on one of the \u201cshelves\u201d for its future deployment on
\none of the environments. The shelf chosen depends on the code branch
\nconsidered. Here are the identified publication paths:<\/p>\n\n
\n\u201cdevelop\u201d => deliverables candidates for the \u201cdevelopment\u201d
\nenvironment<\/li>\n<\/ul>\n\n
\nbranch => candidate deliverables for the pre-production environment <\/li>\n<\/ul>\n\n
\nbranch => deliverable candidates for the staging environment<\/li>\n<\/ul>\n\n
\nother branch => no publication of the deliverable (it can still be retrieved
\nif desired for testing)<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n
\nautomate various operations. (some will prefer to keep control of these
\noperations or integrate them into the next step: the deployment phase)<\/p>\n\n
\npromotion > pre-production <\/p>\n\n
\n\u201cdevelop\u201d to \u201crelease\u201d <\/li>\n<\/ul>\n\n
\nreset the patch version to \u20180\u2019 on \u2018develop\u2019.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n
\npromotion > production<\/p>\n\n
\n
\n
\nstaging > production <\/p>\n\n
\n\u201chotfix\u201d to \u201cmaster\u201d <\/li>\n<\/ul>\n\n
\n
\none question often comes up in the teams: should we orchestrate all this into
\none big job or into several separate jobs? The answer is somewhere in between
\nand depends on your progress in implementing the different steps of continuous
\nintegration. However, some principles are important to consider:<\/p>\n\n
\ndeployment of an existing deliverable must be possible at any time, regardless
\nof the stages of construction of that deliverable.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
\nenvironment must be possible at any time, without depending on the stages of
\nconstruction and promotion of deliverables.<\/p>\n Dis-continuous integration <\/h2>\n
![\"Discontinuous](\"https:\/\/blog.atinternet.com\/wp-content\/uploads\/2019\/09\/Discountinuous-Integration.png\")
\nflow that allows continuous delivery in production requires a certain number of
\nautomatisms and tools that are safety ramparts that allow products to be
\ngradually validated until they are put into production. Some elements are often
\nmissing in the chain to give full responsibility to scripts and other test
\nrobots for the \u201cdecision\u201d to deliver to production. Here is the order
\nin which these elements are often put in place, in the evolution of R&D:<\/p>\n\n
\nof the deliverable (build)<\/li>\n
\ntests<\/li>\n
\nscripts<\/li>\n
\nquality<\/li>\n
\nof tests<\/li>\n
\nmechanisms<\/li>\n<\/ol>\n
\nmore of these elements are missing, the operation remains manual. The rest of
\nthe operations are then also manually triggered, if automatisms are present to
\ncontinue. We are then in a situation that I would describe as dis-continuous
\nintegration.<\/p>\n
\nlevel of maturity, all operations are automated, but we are not yet ready to do
\nwithout manual actions to trigger production releases. This is often the case
\nif all the mechanics are available but the tests on the different environments
\nare too limited. We still need to reassure ourselves with a few manual actions
\nto \u201creceive\u201d and increase our level of confidence.<\/p>\n
\nare only intervening to trigger further operations, simply based on the status
\ndisplayed by some systems. We can then link this operation to the rest of the
\nchain because our action no longer brings any added value. Moving to this stage
\nof continuous delivery also requires good production monitoring systems to be
\nconfident that the system will be resilient to a failure that has gone through
\nthe various validation steps without being detected. This may be the subject of
\na future article!<\/p>\n<\/div>\n\n","protected":false},"excerpt":{"rendered":"