DevOps Transformation for Enhanced Agility

Why change architecture to a cloud-based architecture?

• Make delivery a non-event
• Defining a Delivery Pipeline

• Goal : Automate infrastructure creation using definition as code
• The manual action of implementing an environment has no added value
• In the event of an incident, code correction, destruction, and reconstruction of an environment from its definition
• Benefits : time saved to build and rebuild an environment and improved scalability of environments

CONFIGURATION AS CODE

Goal : Ensure the same runtime configuration across all environments

• Using YAML to Describe Configuration
• Storing the configuration with the source code
• Consolidates application and runtime configuration

The configuration is built at the same time as the construction of the application binary

Benefits : Regardless of the platform, the application works with the same runtime environment

PIPELINE AS CODE

Objective : to be able to deploy at any time with the Pipeline

As soon as a source code is pushed to GIT, the integration pipeline is triggered

• Packaging of the “Release candidate” application and its configuration
  • Building the application binary
  • Building Docker images
• Execution of all Automated Tests: Automated Unit or Integration Testing …
  • In case of an error in the execution of the tests:
    • Deployment is interrupted
    • The team is informed in order to correct as soon as possible
• Deployment to the integration environment
  • Database update
  • Deploying Application Components

Benefits : Deployment of stable versions, deployment on the “Integration” environment is only done if all automated tests are passed.

LIVING DOCUMENTATION

Objective : to bring documentation to life in the same cycle as the source code

• Document the product throughout its construction

• Build functional and technical documentation
  • The documentation produced corresponds to what is completed
  • Build technical documentation from source code elements

Benefits : Up-to-date and easily maintainable documentation

SSOT: SINGLE SOURCE OF TRUST

Objective : To have a single repository for ANY element of the project (Single Repository Of Trust)

Application

• Application source code, as well as dependencies (libraries, static content, etc.)
• All DB schema creation scripts, reference data, etc.
• All automated testing, as well as manual scenarios
• Any other artifacts of the project (functional documentation, technical documentation, release notes, etc.)

Packaging & Environments

• All scripts allowing the packaging of the application, deployment, migration of data from the database and provisioning of environments
• All of the tools for creating environments and artifacts described in the previous items
• All files used to create containers (e.g. Docker file)

Configuration

• All cloud platform configuration files
• Any other scripts needed to configure the product in its environment

PLUGGED BY ABSTRACTION AND FEATURE FLIPPING

Example of a project context:

• There can be several iterations in parallel at different phases in the production cycle (technical design, development, correction of internal anomalies, correction of acceptance anomalies, etc.)
• Each iteration brings its share of corrections and changes
• It is necessary to be able to deliver each iteration with the relevant content
• There are several possible strategies

Use branches:

• Involves the multiplication of Merges

A Merge Isn’t Always Automatic

A Merge is never done serenely

A merge is ultimately a set of standard code changes: requires testing each element of the merge

• Increased risk of regression
• Generates complexity

A branch can diverge drastically from the master’s degree

A branch can be maintained for several weeks, months, etc.

A Merge Is Potentially Impossible

• This sometimes means re-implementing the solution
• Not an ideal candidate for continuous integration

Who advocates a single job on the master’s degree

Who considers that the multiplication of jobs is complicated

• Holding back a continuous deployment / DevOps approach

Branch by abstraction

• Simply don’t use branches (at least not necessarily one by iteration)
• No branch→ No merge
• All developments are carried out on the master
• Incomplete jobs are disabled by the use of feature flags
• The master is always stable, ready to be delivered

Feature Flipping

• Ability to enable and disable features at any time
• Allows you to enable features for certain users only
• If there is a problem, there is no going back, only deactivation.
• Ability to push unfinished code
• Avoiding Merge Problems

Feature Flipping is a practice related to continuous deployment

• Used by the big web: Flickr, Facebook, Gmail, Netflix, Yellow Pages

RELEASE MANAGEMENT

• Separating the concept of release from that of deployment
• Possibility of using a Blue-Green Deployments technique
• Possibility of using a Canary Release technique

Ability to use a Dark Launch technique

• This pattern makes it possible to deploy the non-visible part of a feature, gradually simulating the traffic that will be generated by the use of the target feature.

• The objective of this pattern is to be able to validate the performance and scalability of the platform. By simulating the expected traffic gradually, we can prepare and optimize the platform so that the opening of the feature to end users takes place in the best conditions on D-Day.

MONITORING

User Behavior Tracking

• Challenge users’ use of the product
  • User Experience Questionnaire
  • Feedback to adjust the Product Backlog
• Monitor the use of functions

Monitoring Environments

• Technical and functional: response time, memory usage, etc.

AUTOMATION

Goal : Reduce manual actions with little value

• Ensure process reproducibility

In the end, it is possible to find actions to automate at any level of the project:

• Infrastructure
• Testing
• Generation of binaries and document deliverables
• Deployment
• Documentation

Process automation ensures that everyone involved in the project is well understood

Benefits : Faster feedback in case of errors and easier promotion of the application on different environments.