MOD 1: DevOps and Infrastructure :

1. DevOps Culture and Practices, Getting started with DevOps,

2. Implementing CI/CD and continuous deployment, Continuous integration (CI), Implementing CI,
Continuous delivery (CD), Continuous deployment,

3. Understanding IaC practices: The benefits of IaC ,IaC languages and tools :Scripting types,
Declarative types,

4. Optimizing Infrastructure Deployment with Packer: Technical requirements, An overview of

Packer, Installing Packer, Installing manually, Installing by script, Installing Packer by script on
Windows, Integrating Packer with Azure Cloud Shell, Checking the Packer installation.
DevOps Culture and Practices
• The term DevOps was introduced in 2007-2009 by Patric Debois, Gene Kim,
and John Willis.
• DevOps is a collection of two words, “Development” and “Operations,”
• It is a collaboration between development and operations teams to streamline the
entire software delivery lifecycle, to handle the complete application lifecycle
from development to testing, operations, and deployment. So that it reduces the
delivery time
• Key elements to facilitate collaboration and improve communication between
Dev and Ops
• More frequent application deployment with integration and continuous
delivery(called CI/CD)
• The implementation, automation and integration tests, with a process focused on
Behavior-Driven Design(BDD) or Test-Driven Design (TDD)
• The implementation of a means of collecting feedback from users
• Monitoring application and infrastructure
The Devops movement is based on three axes:

• The culture of collaboration : Collaboration of development and ops team that have the same
objective: to deliver added value to the product as quickly as possible.

• Processes:

• These processes should not only be integrated into the development workflow with continuous
integration but also into the deployment workflow with continuous delivery and deployment.

• The DevOps process is divided into several phases:

 The planning and prioritization of functionalities

 Development

 Continuous integration and delivery

 Continuous deployment

 Continuous monitoring
Tools: when teams were separated into Dev and Ops, each team used their specific tools

• deployment tools for developers and infrastructure tools for Ops which further widened
communication gaps.

• Since dev and ops team are collaborating tools used must be usable and exploitable by all the
members

• Developers need to integrate with monitoring tools used by Ops teams to detect performance
problems as early as possible and with security tools provided by Ops to protect access to
various resources.

• on the other hand, must automate the creation and updating of the infrastructure and integrate
the code into a code manager; this is called Infrastructure as Code, but this can only be
done in collaboration with developers who know the infrastructure needed for applications
• the three axes of Devops culture-the collaboration between Dev and Ops, the processes, and
the use of tools:
• Devops is the union of people, process, and products to enable continuous delivery of
value to our end users."

• The benefits of establishing a Devops culture within an enterprise are as follows:

 Better collaboration and communication in teams, which has a human and social
impact within the company.
 Shorter lead Times to production, resulting in better performance and end user
satisfaction
 Reduced infrastructure costs with IaC.
 Significant time saved with iterative cycles that reduce application errors and
automation tools that reduce manual tasks, so teams focus more on developing
new functionalities with added business value
Implementing CI/CD and continuous deployment

Continuous integration (CI)

• Continuous Integration is a software development practice where members of a team

integrate their work frequently... Each integration is verified by on automated build
{including test) to detect integration errors as quickly as possible.”

• CI requires the implementation of processes (branch, commit, pull request, code review, and
so on) with automation that is done with tools adapted to the whole team (Git, Jenkins, Azure
Devops, and so on).

• And finally, CI must run quickly to collect feedback on code integration as soon as possible
and hence be able to deliver new features more quickly to users
Implementing CI

• To setup CI, it is, necessary to have a Source Code Manager (SCM) that will allow the centralization of
the code of all members.

• This code manager can be of any type: Git, SVN, or Team Foundation Source Control (TFVC).

• It's also important to have an automatic build manager (CI server) that supports continuous
integration such as Jenkins, GitLab CI, TeamCity, Azure Pipelines, GitHub Actions, Travis CI, Circle
CI, and so on.

• The initial step of CI process is integration of all the commits

• This process, executed by the CI server, must be automated and triggered at each commit. The server
will retrieve the code and then do the following:

• Build the application package—compilation, file transformation, and so on.

•
• This diagram shows the cyclical steps of continuous integration that include the code being
pushed into the SCM by the team members and the execution of the build and test by the CI
server.

• And the purpose of this last process is to provide rapid feedback to members. We have just
seen what continuous integration is, so now let's look at continuous delivery

• CI process must be optimized as soon as possible so that it can run fast, and developers can
have quick feedback on the integration of their code.

• With an optimized and complete CI process, the developer can quickly fix their problem and
improve their code or discuss it with the rest of the team and commit their code for a new
integration:
Continuous delivery (CD)

• Once continuous integration is completed, the next step is to deploy the application automatically in one or
more non-production environments, which is called staging. This process is called continuous delivery (CD).

• CD often starts with an application package prepared by CI, which will be installed according to a list
of automated tasks. These tasks can be of any type: unzip, stop and restart service, copy files, replace
configuration, and so on.

• The execution of functional and acceptance tests can also be performed during the CD process.

• CD aims to test the entire application with all its dependencies

• It is very important that the package generated during CI and that will be deployed during CD is the same one
that will be installed on all environments,

• This immutable, unchangeable character of the code is the only guarantee that the application verified in an
environment will be of the same quality as the version deployed in the previous environment and the same
one that will be deployed in the next environment.
• The tools set up low CI/CD are often completed with other solutions, which are
as follows:

• A package manager: This constitutes the storage space of the packages

generated by CI and recovered by CD.

• These managers must support Needs, versioning, and different types of

packages. There are several on the market, such as Mexus, ProGet, Artifactory,
and Azure Artifacts. •

• A configuration manager: This allows you to manage configuration changes

during CD; most CD tools include a configuration mechanism with a system of
variables.
• the deployment of the application in each staging environment is triggered as follows:

1. It can be triggered automatically, following a successful execution on a previous

environment.

For example, we can imagine a case where the deployment in the pre-production
environment is automatically triggered when the integration tests have been successfully
performed in a dedicated environment.

2. It can be triggered manually, for sensitive environments such as the production

environment, following a manual approval by a person responsible for validating the
proper functioning of the application in an environment.

• What is important in a CD process is that the deployment to the production environment,

that is, to the end user, is triggered manually by approved users:
• This diagram clearly shows that the CD process isa continuation o1 the CI process. It represents
the chain of CD steps, which are automatic for staging environments but manual for production
deployments. It also shows that the package is generated by CI and is stored in a package
manager and that it is the same package that is deployed in different environments.

Continuous deployment

• Continuous deployment can be implemented with the use and implementation of feature toggle
techniques (or feature flags), which involves encapsulating the application's functionalities in
features and activating its features on demand, directly in production, without having to redeploy
the code of the application.

• Another technique is to use a blue-green. production infrastructure, which consists of two

production environments, one blue and one green. We first deploy to the blue environments,
then to the green; this will ensure that there is no downtime required:
• CI/CD processes are therefore an essential part of Devops culture, with CI allowing teams to integrate and test
the coherence of its code and to obtain quick feedback very regularly. CD automatically deploys on one or more
staging environments and hence offers the possibility to test the entire application until it is deployed in
production. Finally, continuous deployment automates the deployment of the application from commit to the
production environment.
• Understanding IaC (Infrastructure as Code ) practices

• IaC is the process of writing the code of the provisioning and configuration steps of
infrastructure components to automate its deployment in a repeatable and consistent manner

• Terraform is an open-source infrastructure as code (IaC) software tool which can be used to
provision the infrastructure of an cloud platform

• The benefits of IaC

• The standardization of infrastructure configuration reduces the risk of error.

• The code that describes the infrastructure is versioned and controlled in a source code
manager

• The code is integrated into CI/CD pipelines.

• It brings benefits to devops team by allowing ops to be more efficient on
infrastructure improvement tasks rather than spending time on manual
configuration and by giving Dev the possibility to upgrade their infrastructure
and make changes without having to ask for more Ops resources

• It allows the creation of self-service, environment that will give developers and
testers more flexibility to test new features in isolation and independently of
another environment
IaC languages and tools

• Languages and tools used to code the infrastructure can be of different types; that is, scripting and
declarative types.

1. scripting

These are scripts such as Bash, power shell, or any other languages that use the different clients (SDKs)
provided by the cloud Provider

For example: commands using Azure CLI : az group create -location westeurope -name MyAppResourcegroup

and Azure powershell: New-AzResourceGroup -Name MyAppResourcegroup -Location westeurope

2. declarative types.

These are languages in which it is sufficient to write the state of the desired system or infrastructure in the form
of configuration and properties.

Example Terraform, Ansible, the azure ARM template

• Terraform code that allows you to define the desired configuration of an Azure resource
group:

resource "azurerm_resource_group" "myrg’ {

name - "MyAppResourceGroup”

location - "West Europe"

tags - { environment- “Bookdemo"

}
• Declarative type
• Optimizing infrastructure Deployment with Packer

Configuring a VM can be very time-consuming because it depends on its hardening as well as the middleware that will be
installed and configured on VM

Between each environment or application, the middleware versions are not identical because their automation script is not
necessarily identical or maintained over time

Configuration and security compliance is not often applied or updated

To address these issues all cloud providers have integrated a service that allows them to create or generate custom VM images.

These images contain all of the configurations of the VMs with their security administration and middleware configurations
and can then be used as a basis to create VMs for applications.
• benefits of using images

• The provisioning of a VM from an image is very fast.

• Each VM is uniform in configuration and, safe

• Among the Infrastructure as Code (IaC) tools, there is Packer from the HashiCorp tools, which allows us to create VM
images from a file (or template )

• To use Packer to create VM image in an Azure infrastructure as an example of cloud infrastructure Azur subscription is
required which is available in https://azur.Microsoft.com/en-us/free/.
• Overview of packer
Packer is part of the HashiCorp open-source suite of tools, and (https://www.packer.io/.)

It allows to create custom VM images of any OS(called templates) on several platform from a JSON file.

Packer’s operation is simple;

It is based on the basic OS provided by the different cloud providers and configures a temporary VM by executing the scripts
described in the JSON template.

Installing Packer: manually

Packer is a cross-platform tool can be installed on windows, linux, macOS

• Installing manually
• Installing by script:

• Installing Packer by script on Windows, Integrating Packer with Azure Cloud

Shell, Checking the Packer installation.
• Integrating Packer with Azure Cloud Shell
• Checking the Packer installation Once installed, we can check the installed version of Packer by running the following
command: packer --version

• To see all of the Packer command-line options, we can execute the following command: packer --help
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T
•T