Devops

Shalini Mittal
Corporate Trainer, Developer & Consultant
Devops
 Communication, collaboration and integration are the three main
principles of the ever-growing, modern approach to software delivery
known as “DevOps.”
 Coined in 2009 by Patrick Debois, the term (development and operations)
is an extension of agile development environments that aims to enhance
the process of software delivery as a whole.
 DevOps is the combination of cultural philosophies, practices, and tools
that increases an organization’s ability to deliver applications and services
at high velocity:
evolving and improving products at a faster pace than organizations using
traditional software development and infrastructure management
processes.
 This speed enables organizations to better serve their customers and
compete more effectively in the market.
Definition
 It sprang from 2 words:
• “agile infrastructure” or “agile operations”
• Collaboration between development and operations team
 a cross-disciplinary community of practice dedicated to the study of
building, evolving and operating rapidly-changing resilient systems
at scale.
 In a generic way, DevOps is the practice of operations and development
engineers participating together in the entire service lifecycle, from design
through the development process to production support.
Devops – next generation of agile
 Back in 2009, more IT professionals started to move away from the
traditional waterfall method and embrace nonlinear agile methodology by
making each development stage independent and incorporating
continuous testing early on and throughout the development cycle
 Agile enables devops to exist
 This approach enhanced efficiency and reduced risk by allowing
developers to make immediate changes before shipping to production
based on the continuous feedback they received
 While development used agile, deployment hung on to the linear waterfall
structure, slowing down delivery and leaving testing to the end of the
process — a process that wrongfully split ownership.
 Marriage of development and operations along with the extended best
practices and principles associated with agile had the potential to greatly
increase efficiency and lower delivery risks
Devops Gloassary
The Cloud – 1/2
 IaaS: Leading cloud vendors such as Amazon Web Services (AWS),
Microsoft Azure, and Google Cloud Platform (GCP). These are
infrastructure as a service (IaaS) vendors that provide computing
resources to customers via a public connection over the Internet in a
virtualized environment. These resources include storage, bandwidth,
virtual servers, load balancers, network connections, and IP addresses.
Examples of vendors and tools: AWS, GCP, Azure, IBM SoftLayer, Digital
Ocean

 PaaS: Platform as a service (PaaS) enables developers to build applications

and services on a cloud-based platform. PaaS offerings may require little
to no client-side hosting expertise and include preconfigured features in
simple frameworks. PaaS providers update their services on a regular basis
with upgrades and new features and offer support to developers from the
start through deployment. PaaS services are generally offered on a pay-
per-use subscription basis.
Examples of vendors and tools: Heroku, Google App Engine, AWS Elastic
Beanstalk
The Cloud – 2/2
 SaaS: If you’re familiar with Google and Facebook, you’ve already been
exposed to software as a service (SaaS). These cloud-hosted software
applications have multiple uses for both individuals or organizations such
as instant messaging, email, performance monitoring, accounting, and
communications, and the tools can easily be accessed online. As opposed
to purchasing traditional software applications that include licensing
limitations, SaaS is subscription-based and applications are used online
and hosted in the cloud.
Integration And Delivery
 Continuous Integration (CI) – developers integrate code into a shared
repository multiple times a day and each isolated change to the code is
tested immediately in order to detect and prevent integration problems.
Examples of vendors and tools: Jenkins, Teamcity, TravisCI, CircleCI

 Continuous Delivery (CD) – As an extension of CI and the next step in

incremental software delivery, continuous delivery (CD) ensures that every
version of the code that is tested in the CI repository can be released at
any moment.
Examples of vendors and tools: Jenkins, TeamCity, TravisCI, Electric
Cloud, Go, Codeship, AWS CodeDeploy

 Continuous Deployment – Continuous deployment can be thought of as

an extension of continuous integration, aiming to have a new code
deployed in production to be used by live users. Supported by CI, when
tests meet the release criteria, it is released immediately.
Configuration Management
 In a nutshell, the process of maintaining up-to-date, detailed records of
hardware and software — including versions, requirements, network
addresses, and design and operational information — is known as
configuration management (CM). You can use CM tools such as Chef,
Puppet, or Ansible to aid the process. You can also use Bash and Python to
build your own configuration management automation.
 Examples of vendors and
tools: Chef, Puppet, Ansible, Saltstack, Vagrant, CFEngine
Resource Orchestration
 When it comes to micro-services, service-oriented architecture, converged
infrastructures, virtualization, and provisioning, the coordination and
integration of computer systems is known as orchestration. By leveraging
defined automated workflows, orchestration makes sure that business
needs are aligned with your IT infrastructure resources.

Containers
 Linux containers are lightweight virtualization components that run
isolated application workloads. They run their own processes, file systems,
and network stacks, which are all virtualized using the root operating
system (OS) running on the hardware.
 Examples of vendors and related
tools: Docker, CoreOs, Kubernetes, Mesos, ElasticBox
Source Version Control
 Version control includes practices and tools that help R&D organizations
maintain and control changes within their source code repository. R&D
members use source control tools to document and track system
configuration files as well.
 Examples of vendors and tools: GitHub, Bitbucket, JFrog, Artifactory

Bug Tracking
 A bug tracker is a system that aggregates and reports software bugs and
defects. It helps R&D organizations with task management and is part of
the consistent feedback loop that the DevOps methodology requires.
 Examples of vendors and tools: BUGtrack, JIRA, GitHub
Test Automation
 Test automation facilitates test engineer work by supporting multiple tests
that run continuously. It enhances test coverage while supporting efficient
release cycles. For example, test automation tools help manage, execute,
and measure functional tests and load tests.
 Examples of vendors and tools:
Selenium, Cucumber, JUnit, TestNG, JMeter
 Unit Test – Unit testing is a process that allows testers to examine small
parts of an application, such as a specific code or module. This test is
usually automated and reused in order to support continuous testing and
integration
Monitoring
 Monitoring is a primary element of IT performance management and is one
of the most important aspects when operating online services. Monitoring
tools are essential and provide crucial information that helps to ensure
service robustness in terms of availability, security, and performance.
 Application Performance Monitoring (APM) – APM allows you to
automatically detect and be alerted about hotspots in your application
framework that include the application and database layers.
Examples of vendors and tools: New Relic, AppDynamics, DataDog
 Infrastructure Monitoring – Tools in this category automatically detect and
alert about degradations in underlying physical or virtual resource
performance and availability.
Examples of vendors and tools: AWS
CloudWatch, Nagios, Zabbix, Sensu, Icynga
Log Management
 Log management (or log analytics) is the practice of dealing with large
volumes of computer-generated messages. They can be operational
messages (e.g., when tracking service performance or security) or for BI
purposes (e.g., when tracking online user behavior).
Vendors and tools: Logz.io (ELK), Splunk, Sumo Logic
GIT
Version Control
 Version control is a system that records changes to a file or set of files over
time so that you can recall specific versions later. So ideally, we can place
any file in the computer on version control.
 A Version Control System (VCS) allows you to revert files back to a previous
state, revert the entire project back to a previous state, review changes
made over time, see who last modified something that might be causing a
problem, who introduced an issue and when, and more
Distributed Version Control
 In a distributed version control system each user has a complete local copy
of a repository on his individual computer.
 The user can copy an existing repository. This copying process is typically
called cloning and the resulting repository can be referred to as a clone.
 Every clone contains the full history of the collection of files and a cloned
repository has the same functionality as the original repository.
GIT?
 Git is a Distributed Version Control System.
 Git originates from the Linux kernel development and was founded in 2005
by Linus Torvalds.
 The core of Git was originally written in the programming language C, but
Git has also been re-implemented in other languages, e.g., Java, Ruby and
Python.
 Helps to synchronise code between multiple people
GIT Repository
 A repository a.k.a. repo is nothing but a collection of source code.
 There are four fundamental elements in the Git Workflow.
 Working Directory, Staging Area, Local Repository and Remote Repository
GIT Workflow
 If you consider a file in your Working Directory, it can be in three possible
states.
 It can be staged. 
Which means the files with the updated changes are marked to be
committed to the local repository but not yet committed.
 It can be modified.
Which means the files with the updated changes are not yet stored in the
local repository.
 It can be committed.
Which means that the changes you made to your file are safely stored in
the local repository.
Alternative versions of file
 Git allows you to add different versions of your files in parallel. For this, Git
uses branches. A branch allows the user to switch between these versions
so that he can work on different changes independently from each other.
 For example, if you want to develop a new feature, you can create a branch
and make the changes in this branch. This does not affect the state of your
files in other branches. For example, you can work independently on a
branch called production for bugfixes and on another branch
called feature_123 for implementing a new feature.
Git Tooling
 The most common tooling for Git is provided as command line tooling via
the git command.
 Without any arguments, this command lists its options and the most
common commands. You can get help for a certain Git command via the
help command online option followed by the command.
 git help [command to get help for]
 See all possible commands, use the git help --all command.
 The Eclipse IDE provides excellent support for working with Git repositories.
https://www.vogella.com/tutorials/EclipseGit/article.html
 Also Visual Studio Code provides excellent build-in support for Git.
Installation
 Microsoft windows
The Git download page provides native installers for the Windows system.
http://git-scm.com/downloads
 Mac OS
The Git download page provides also natives installer for Mac OS X. Git is
also installed by default with the Apple Developer Tools on Mac OS X.
 Ubuntu, Debian and derived systems
On Ubuntu and similar systems you can install the Git command line tool via
the following command:
sudo apt-get install git
Git Configuration
 The git config command allows you to configure your Git settings. These
settings can be system wide, user or repository specific.
 A more specific setting overwrites values in the previous level. A setting for
the repository overrides the user setting and a user setting overrides a
system wide setting.
 Git allows you to store user settings in the .gitconfig file located in the user
home directory. This is also called the global Git configuration.
 You can also store repository specific settings in the .git/config file of a
repository. Use the --local or use no flag at all. If neither the --system not
the --global parameter is used, the setting is specific for the current Git
repository.
User Credential Configuration
 You have to configure at least your user and email address to be able to
commit to a Git repository because this information is stored in each
commit.
 # configure the user which will be used by Git
# this should be not an acronym but your full name
git config --global user.name "Firstname Lastname"
# configure the email address
git config --global user.email "your.email@example.org"
Configure files to ignore
 Git can be configured to ignore certain files and directories for repository
operations. This is configured via one or several .gitignore files. Typically,
this file is located at the root of your Git repository but it can also be
located in sub-directories. In the second case the defined rules are only
valid for the sub-directory and below.
 You can use certain wildcards in this file. * matches several characters
 You can create the .gitignore file in the root directory of the working tree to
make it specific for the Git repository.
 Example :
# ignore all bin directories
# matches "bin" in any subfolder
bin/
# ignore all target directories
target/
# ignore all files ending with ~
*~
Git basic commands
 git add is a command used to add a file that is in the working directory to
the staging area.
 git commit is a command used to add all files that are staged to the local
repository.
 git push is a command used to add all committed files in the local
repository to the remote repository. So in the remote repository, all files
and changes will be visible to anyone with access to the remote repository.
 git fetch is a command used to get files from the remote repository to the
local repository but not into the working directory.
 git merge is a command used to get the files from the local repository into
the working directory.
 git pull is command used to get files from the remote repository directly
into the working directory. It is equivalent to a git fetch and a git merge .
GIT Local repo
Create directory
 The following commands create an empty directory .
# switch to the home directory
cd
# create a directory and switch into it
mkdir repo01
cd repo01
# create a new directory
mkdir datafiles
Create a new Git repository
 You now create a new local repository. Use the git init command to create a
Git repository in the current directory. Git does not care whether you start
with an empty directory or if it contains already files.
 # initialize the Git repository for the current directory should be repo01
git init
 All files inside the repository folder, excluding the .git folder, are the
working tree.
Create new Content
 Create a few new files in your directory. For example, the following
commands create a few files in a bash shell.
 # ensure that you are in your Git Git repository
# create an empty file in a new directory
touch datafiles/data.txt
# create a few files with content
ls > test01
echo "bar" > test02
echo "foo" > test03
Current status
 View the status of your repository via the following command.
 git status
 The output looks similar to the following listing.
On branch master

Initial commit

Untracked files:
(use "git add <file>..." to include in what will be committed)

datafiles/
test01
test02
test03

nothing added to commit but untracked files present (use "git add" to track)
Add changes to staging area
 Inform git that all new files should be added to the Git repository with
the git stage command.
# add all files to the index of the Git repository
git stage .
# if stage is not available use git add instead, stage was added around 2020
to the git command line
 Afterwards run the git status command again to see the current status.
Change files that are staged
 Adjust an existing file.
# append a string to the test03 file
echo "foo2" >> test03
 Validate that the new changes are not yet staged.
 Add the new changes to the staging area.
 # add all files to the index of the Git repository
git stage . OR git add .
 Use the git status command again to see that all changes are staged.
Commit changes
 Commit the staged changes to your Git repository.
# commit your file to the local repository
git commit -m "Initial commit”
 The commit operation, created a new version of your files in the local
repository inside the .git folder. Run the git log command to see the history.
 # show the Git log for the change
git log
 Use the git show command to see the changes of a commit.
 Review the directory structure
GIT Remote repo
Remote Repositories
 Git allows that you can synchronize your repository with more than one
remote repository.
 In the local repository you can address each remote repository by a
shortcut. This shortcut is simply called remote. Such a remote repository
point to another remote repository that can hosted on the Internet, locally
or on the network.
Cloning Repositories
 Make a git account
https://github.com/join
 Make sure you have git installed
$ git –version
 All the changes we made in the file are updated in the local repository. Now
to update the changes to the master:
git remote add origin remote_repository_URL# sets the new remote
Any Question ?