UNIT 5

Agile Methodology(1), ADAPTing to Scrum(2), Patterns for Adopting Scrum(3),

Iterating towards Agility(4).
Fundamentals of DevOps: Architecture(7), Deployments(8), Orchestration(10),
Need(11), Instance of applications(12), DevOps delivery pipeline(12), DevOps eco
system.(13)
DevOps adoption in projects: Technology aspects(13), Agiling capabilities(14), Tool stack
implementation(14), People aspect(16), processes(17).

Agile Methodology
Agile Software Development is a software development methodology that values flexibility,
collaboration, and customer satisfaction. It is based on the Agile Manifesto, a set of principles
for software development that prioritize individuals and interactions, working software,
customer collaboration, and responding to change.
Agile Software Development is an iterative and incremental approach to software
development that emphasizes the importance of delivering a working product quickly and
frequently. It involves close collaboration between the development team and the customer
to ensure that the product meets their needs and expectations.

The Agile Software Development process typically consists of the following steps:
1. Requirements Gathering: The customer’s requirements for the software are
gathered and prioritized.
2. Planning: The development team creates a plan for delivering the software,
including the features that will be delivered in each iteration.
3. Development: The development team works to build the software, using frequent
and rapid iterations.
4. Testing: The software is thoroughly tested to ensure that it meets the customer’s
requirements and is of high quality.
5. Deployment: The software is deployed and put into use.
6. Maintenance: The software is maintained to ensure that it continues to meet the
customer’s needs and expectations.

Agile Software Development is widely used by software development teams and is

considered to be a flexible and adaptable approach to software development that is well-
suited to changing requirements and the fast pace of software development.
Agile is a time-bound, iterative approach to software delivery that builds software
incrementally from the start of the project, instead of trying to deliver all at once.

Principles:
1. Highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
2. It welcomes changing requirements, even late in development.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shortest timescale.
4. Build projects around motivated individuals. Give them the environment and the
support they need, and trust them to get the job done.
5. Working software is the primary measure of progress.
6. Simplicity the art of maximizing the amount of work not done is essential.
7. The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.

Downloaded by Praneeth Varma ([email protected])

Development in Agile: Let’s see a brief overview of how development occurs in Agile
philosophy.
 In Agile development, Design and Implementation are considered to be the central
activities in the software process.
 Design and Implementation phase also incorporates other activities such as
requirements elicitation and testing into it.
 In an agile approach, iteration occurs across activities. Therefore, the requirements
and the design are developed together, rather than separately.
 The allocation of requirements and the design planning and development as executed
in a series of increments. In contrast with the conventional model, where requirements
gathering needs to be completed in order to proceed to the design and development
phase, it gives Agile development an extra level of flexibility.
 An agile process focuses more on code development rather than documentation.

Example: Let’s go through an example to understand clearly how agile actually works. A
Software company named ABC wants to make a new web browser for the latest release of
its operating system. The deadline for the task is 10 months. The company’s head assigned
two teams named Team A and Team B for this task. In order to motivate the teams, the
company head says that the first team to develop the browser would be given a salary hike
and a one-week full-sponsored travel plan. With the dreams of their wild travel fantasies, the
two teams set out on the journey of the web browser. Team A decided to play by the book
and decided to choose the Waterfall model for the development. Team B after a heavy
discussion decided to take a leap of faith and choose Agile as their development model. The
Development plan of the Team A is as follows:
 Requirement analysis and Gathering – 1.5 Months
 Design of System – 2 Months
 Coding phase – 4 Months
 System Integration and Testing – 2 Months
 User Acceptance Testing – 5 Weeks
The Development plan for the Team B is as follows:
 Since this was an Agile, the project was broken up into several iterations.
 The iterations are all of the same time duration.
 At the end of each iteration, a working product with a new feature has to be
delivered.
 Instead of Spending 1.5 months on requirements gathering, They will decide the
core features that are required in the product and decide which of these features
can be developed in the first iteration.
 Any remaining features that cannot be delivered in the first iteration will be
delivered in the next subsequent iteration, based on the priority
 At the end of the first iterations, the team will deliver working software with the
core basic features.
Both the team have put their best efforts to get the product to a complete stage. But then out
of blue due to the rapidly changing environment, the company’s head come up with an
entirely new set of features and want to be implemented as quickly as possible and wanted
to push out a working model in 2 days. Team A was now in a fix, they were still in their
design phase and did not yet start coding and they had no working model to display. And
moreover, it was practically impossible for them to implement new features since waterfall
model there is not reverting back to the old phase once you proceed to the next stage, which
means they would have to start from the square one again. That would incur their heavy cost

Downloaded by Praneeth Varma ([email protected])

and a lot of overtime. Team B was ahead of Team A in a lot of aspects, all thanks to Agile
Development. They also had the working product with most of the core requirements since
the first increment. And it was a piece of cake for them to add the new requirements. All they
had to do is schedule these requirements for the next increment and then implement them.

Advantages:
 Deployment of software is quicker and thus helps in increasing the trust of the
customer.
 Can better adapt to rapidly changing requirements and respond faster.
 Helps in getting immediate feedback which can be used to improve the software
in the next increment.
 People – Not Process. People and interactions are given a higher priority rather
than process and tools.
 Continuous attention to technical excellence and good design.
 Increased collaboration and communication: Agile methodologies emphasize
collaboration and communication among team members, stakeholders, and
customers. This leads to improved understanding, better alignment, and increased
buy-in from everyone involved.
 Flexibility and adaptability: Agile methodologies are designed to be flexible and
adaptable, making it easier to respond to changes in requirements, priorities, or
market conditions. This allows teams to quickly adjust their approach and stay
focused on delivering value.
 Improved quality and reliability: Agile methodologies place a strong emphasis on
testing, quality assurance, and continuous improvement. This helps to ensure that
software is delivered with high quality and reliability, reducing the risk of defects
or issues that can impact the user experience.
 Enhanced customer satisfaction: Agile methodologies prioritize customer
satisfaction and focus on delivering value to the customer. By involving customers
throughout the development process, teams can ensure that the software meets
their needs and expectations.
 Increased team morale and motivation: Agile methodologies promote a
collaborative, supportive, and positive work environment. This can lead to
increased team morale, motivation, and engagement, which can in turn lead to
better productivity, higher quality work, and improved outcomes.
Disadvantages:
 In case of large software projects, it is difficult to assess the effort required at the
initial stages of the software development life cycle.
 The Agile Development is more code focused and produces less documentation.
 Agile development is heavily depended on the inputs of the customer. If the
customer has ambiguity in his vision of the final outcome, it is highly likely for
the project to get off track.
 Face to Face communication is harder in large-scale organizations.
 Only senior programmers are capable of taking the kind of decisions required
during the development process. Hence it’s a difficult situation for new
programmers to adapt to the environment.
 Lack of predictability: Agile Development relies heavily on customer feedback
and continuous iteration, which can make it difficult to predict project outcomes,
timelines, and budgets.

Downloaded by Praneeth Varma ([email protected])

  Limited scope control: Agile Development is designed to be flexible and
adaptable, which means that scope changes can be easily accommodated.
However, this can also lead to scope creep and a lack of control over the project
scope.
 Lack of emphasis on testing: Agile Development places a greater emphasis on
delivering working code quickly, which can lead to a lack of focus on testing and
quality assurance. This can result in bugs and other issues that may go undetected
until later stages of the project.
 Risk of team burnout: Agile Development can be intense and fast-paced, with
frequent sprints and deadlines. This can put a lot of pressure on team members
and lead to burnout, especially if the team is not given adequate time for rest and
recovery.
 Lack of structure and governance: Agile Development is often less formal and
structured than other development methodologies, which can lead to a lack of
governance and oversight. This can result in inconsistent processes and practices,
which can impact project quality and outcomes.

Agile is a framework that defines how software development needs to be carried on. Agile is
not a single method, it represents the various collection of methods and practices that follow
the value statements provided in the manifesto. Agile methods and practices do not promise
to solve every problem present in the software industry (No Software model ever can). But
they sure help to establish a culture and environment where solutions emerge.
Agile software development is an iterative and incremental approach to software
development. It emphasizes collaboration between the development team and the customer,
flexibility and adaptability in the face of changing requirements, and the delivery of working
software in short iterations.

ADAPTing TO SCRUM
SCRUM
Scrum is a framework for product management commonly used in software development,
although it has been used in other fields including research, sales, marketing and advanced
technologies. It is designed for teams of ten or fewer members who break their work
into goals that can be completed within time-boxed iterations, called sprints. Each sprint is no
longer than one month and most commonly lasts two weeks. The scrum team assesses progress
in time-boxed daily meetings of up to 15 minutes, called daily scrums (a stand-up meeting). At
the end of the sprint, the team holds two further meetings: one sprint review intended to
demonstrate the work done for stakeholders and solicit feedback, and one sprint
retrospective intended to enable the team to reflect and improve.
When we talk about adopting any new framework or methodology, we think about how we can
incorporate these changes into our organization. We simply cannot impose any change in our
organization and get started with it, there has to be some process or ways to incorporate that.
Also, there are some ways to incorporate Scrum changes within our organization. There include
five activities in adopting the Scrum successfully:
1. Awareness
2. Desire
3. Ability
4. Promotion
5. Transfer

Downloaded by Praneeth Varma ([email protected])

So to remember, we call it by the acronym ADAPT.

ADAPT- Awareness
Awareness that the current process is not delivering acceptable results.Change begins
with an awareness that the status quo is no longer desirable. However, becoming aware that
what worked in the past is no longer working can be extremely difficult. Lack of exposure to
the big picture is one of the common reasons behind developing awareness for the need to
change. Instead of list a lot of common problem a project faces every day, focus on the two,
or three major problem that reflect the need of change.
Awareness Tools:
1. Communicate that there’s a problem
2. Use metrics
3. Provide exposure to new people and experiences
4. Run a pilot project
5. Focus attention on the most important reasons to change.

ADAPT- Desire
Desire to adopt Scrum as a way to address current problems. Beyond being aware of the
need to change, one must also have the desire to change. Moving from an awareness that the
current development process isn’t working to the desire to use a different one can be very
hard for many people.
Example “I am aware that I should eat more vegetables; I don’t yet desire to make that
change in my diet”
Desire Tools
 Communicate that there’s a better way
 Create a sense of urgency
 Build momentum
 Get the team to take Scrum for a test drive
 Align incentives(or at least remove disincentives)
 Focus on addressing fear
 Help people let go
 Don’t discredit the past
 Engage employees in the effort

ADAPT- Ability
Ability to succeed with Scrum. All of the awareness and desire in the world won’t get a
team anywhere if it does not also acquire the ability to be Agile. Succeeding with Scrum
requires team members not only to learn new skills but also to unlearn old ones. Some of the
larger challenges Scrum teams will face include the following:
 Gaining new technical skills.
 Learning to think and work as a team.
 Practicing how to create working software within short time-boxes.

Ability Tools
 Provide coaching and training.
 Hold individuals accountable.
 Share information.
 Set reasonable targets.
 Just do it.

Downloaded by Praneeth Varma ([email protected])

ADAPT- Promotion
Promotion of Scrum through sharing experiences so that we remember and others can see
our successes. There are three goals during promotion. The first is to lay the groundwork for
the next pass through the ADAPT cycle. By promoting current successes you will have a
jump start on creating awareness for the next round of improvements. The second goal is to
reinforce Agile behavior on existing teams by spreading the news of the good things those
teams have achieved. Finally, the third goal is to create awareness and interest among those
outside the groups directly involved in adopting Scrum.
Promotion Tools
 Publicize the success stories
 Host an Agile safari
 Attract attention and interest

ADAPT- Transfer
Transfer of the implications of using Scrum through out the company.It is impossible for a
development team to remain Agile on its own permanently. If the implications of using
Scrum are not transferred to other departments, organizational gravity from those
departments will eventually stall and kill the transition effort. Rest of the organization must
become at least compatible with Scrum.
The following is a list of groups to whom you must transfer the implications of using Scrum.
These groups are fundamental participants in Scrum rather than groups to which the effects of
Scrum are transferred.
 Human resources
 Facilities
 Marketing
 Finance
There are groups beyond above mentioned one where scrum implications must be transferred.
For example, project management office, sales, information technology, operations, hardware
development, and other groups with organizational gravity. Transferring the implications of
Scrum to them will be important for long-term success

PATTERNS FOR ADOPTING SCRUM

Start Small or Go All In
Organizations go ahead with it like a Pilot project, like selecting few team members and
implementing Scrum with them, It's a ‘Start Small’ pattern. The other approach can be Go
All In, which is like the executives are convinced and want the whole organization to
implement in one go.

Reasons to prefer starting small

 It’s less expensive
 Early success guaranteed
 Avoids risks of going all in
 Less stressful
 Can be done without much change

Downloaded by Praneeth Varma ([email protected])

Reasons to prefer going all in
 Reduces resistance
 Avoids problems within different teams
 The All-in transition is Quick!

Choosing between the two

As recommended by Mike Cohn, one should always Start Small! It involves less cost, and
guaranteed early success. Going all in should be in limited cases, only when it’s a quick
need. Also, it involves more cost/money as there are a lot of changes in different
departments if required.

Public Display of Agility or Stealth

The next pattern that comes into the picture is whether to Publicize it or not. We can do
the Public Display of Agility. In this approach, the organization announces that it is
adopting Scrum. This can vary from announcing it in a meeting room to announcing it
through the press release.
The other approach is Stealth transition. In this, only team members know they are using
Scrum until the project is complete.

Reasons for Public Display of Agility

 Everyone knows that team is doing it and they are more likely to be focussed
 Operating publicly is a firm statement of commitment
 You can solicit organizational support
 It sends a powerful message

Reasons for Stealth Transition

 A chance to make progress before resistance starts
 It keeps pressure off
 No one knows until you tell them
 If no one knows, no one can tell you to stop

Choosing between the two

As recommended , always choose to make a public display of Agility when you are
confident and committed to the transition and when you expect a lot of resistance but want
to overcome it quickly.

Downloaded by Praneeth Varma ([email protected])

In contrast, choose a quiet approach, when you want to do an experiment using Scrum.

PATTERNS FOR SPREADING SCRUM

Getting started with Scrum is one thing, spreading it across the organization is another.
Unless you choose an all-in transition, you will need to build upon the successes of the
first few teams as you move Scrum to other teams.
There are 3 general patterns given by Mike Cohn that talks about spreading Scrum.

Split and Seed

This talks about taking a team that has begun to be successful with Scrum and using its
team members to seed new teams.
It’s typically put to use after the first few teams have successfully implemented and
adopted Scrum. By this time, each team member understands how Sprint work and how
the ready software is delivered at the end of the sprint.
In Split and Seed pattern, we split one functioning Scrum team into each half of the
original team forming the basis of the new team. New people are then added to these split
teams to form new Scrum teams.
A large initial team is used to seed as many as four new teams. Collated below are the
reasons to prefer Split and Seed pattern.
 Add teams more quickly
 Each team has someone with Scrum experience to guide them

Grow and Split

The Grow and Split pattern involve adding team members until the team is large enough
that it can be comfortably split in two. Immediately after splitting, each of the new teams
will probably be on the small end of the desirable size ranging five to nine members. After
allowing the new teams one sprint at this reduced size, new members are added until each
team becomes a large enough that it can also be split. This pattern repeats until the entire
organization has transitioned.
In following cases, you can prefer Grow and Split pattern.
 Don’t have to destroy any existing teams
 Team members feel more continuity from sprint to sprint

Internal Coaching
The Third pattern of Spreading Scrum is Internal Coaching. In the organizations, there
include types of teams. Some teams excel with the new agile approach, while others

Downloaded by Praneeth Varma ([email protected])

struggle. On each team, there exists one identified person who understands and implement
Scrum successfully. That person is assigned as a Coach for other teams.
Coaches were given responsibilities to attend sprint meetings, daily scrum each week and
coach other teams.
Reasons to prefer Internal Coaching
 Well running teams do not need to be Split
 Coaches can be selected for new teams
 Coaches can move from team to team

Choosing your Pattern!

In general, consider going with Split and Seed pattern, when in a hurry. It is the fastest way
of spreading Scrum. However, if the technology doesn’t support moving people among
teams, changing the team members can affect the productivity.
The Grow and Split pattern is simply more natural and direct approach. Consider using this
approach if there is no sense of urgency as it is less risky.
Internal Coaching can be used on its own, mostly when the group is large enough and when
splitting teams are not possible for the projects.

INTRODUCING NEW TECHNICAL PRACTICES

One final decision facing change agents, Scrum Masters, and new Scrum team members
themselves is how soon the team should adopt new technical practices.

Reasons to Start Soon

There are three very good reasons for putting an early emphasis on adopting new
technical practices:
 Very rapid improvements are possible. Many of the technical practices can provide
some quick wins to the team and organization. Pair programming, for example, can
help cross-train programmers across more areas of the system. Introducing a
continuous build process can reduce integration hassles to near zero. Other
practices—test-driven development, for example—have steeper learning curves, but
even these are measured in days and weeks rather than months and years.

 If the team doesn’t try new technical practices early, it might never try them. Too
many Scrum teams adopt the bare minimum of Scrum and stop there, deciding that
the improvements already achieved through their new iterative and incremental work
style are sufficient. By not considering or trying new or improved technical practices,
these teams forgo much of the improvement they could have made.

 It may address the project’s most pressing issues. Introducing a team to the agile
technical practices can solve an array of typical project problems including poor
quality, over-engineered solutions, long delivery cycles, and so on. There are other
problems, though, that are not addressed by introducing these practices. For example,
a project with a disengaged product owner will experience slow or incorrect decision

Downloaded by Praneeth Varma ([email protected])

 making. This problem will not be remedied solely by introducing new technical
practices.

Reasons to Delay
Just as there are strong reasons for encouraging a team to adopt new engineering
practices early, there are also reasons why it may be better to wait:
 There may be strong resistance to some practices. Introducing certain technical
practices can be one of the most difficult challenges you face when transitioning.
Many individuals are extremely reluctant to try new things, such as simple design,
pair programming, and test-driven development. Although you may have good
reasons to push the team to try new Reasons to Delay

Just as there are strong reasons for encouraging a team to adopt new engineering
practices early, there are also reasons why it may be better to wait:
 There may be strong resistance to some practices. Introducing certain technical
practices can be one of the most difficult challenges you face when transitioning.
Many individuals are extremely reluctant to try new things, such as simple design,
pair programming, and test-driven development. Although you may have good
reasons to push the team to try new technical practices.

ITERATING TOWARDS AGILITY

Following an iterative transition process—making small changes on a continual basis—is a

logical way to adopt a development process that is itself iterative. Doing so will be much
more likely to result in a successful and sustainable transition.

The Improvement Backlog

Just as Scrum development projects use product backlogs, you should use an improvement
backlog to track the effort of adopting Scrum in your organization. An improvement backlog
lists everything that the organization could do better in its use of Scrum. When IBM began
to adopt Scrum, its improvement backlog included the following items:
 Increase the number of teams using Scrum.
 Increase adoption of test automation.
 Enable teams to implement continuous integration.
 Figure out how to make sure each team has a product owner.
 Determine how we’re going to measure the impact of adopting Scrum.
Increase the use of unit testing and test-driven development.

The Enterprise Transition Community

The small group that initiates, encourages, and supports an organization’s effort to introduce
and improve at Scrum is known as the Enterprise Transition Community, or ETC. The
Enterprise Transition Community exists to create a culture and environment where change

Downloaded by Praneeth Varma ([email protected])

can be released by those who are passionate about the success of the organization and where
success leads to more passion from more people.
The ETC does this not by imposing changes on the organization but by guiding groups who
are implementing changes, by removing obstacles to doing Scrum well, and by creating
energy and excitement for the change. The members of the ETC, who usually number no
more than a dozen come from the highest level involved in the transition to Scrum. If a
company is adopting Scrum organization-wide, the ETC should include senior people from
engineering or development plus vice presidents of groups such as product management,
marketing, sales operations, human resources, and so on.
For a departmental adoption of Scrum, the ETC may include the vice president of
engineering along with the heads of QA, development, architecture, interaction design,
database, and so on. The key here is that the ETC is made up of the most senior people for
the level at which the transition is occurring.

ETC Sprints
Because the ETC uses Scrum, it makes progress in sprints, exactly like a Scrum development
team would. Each ETC sprint begins with a planning meeting and ends with a review and
retrospective. These meetings are completely analogous to those held by Scrum
development teams and often have the same problems.

The Sponsor and Product Owner

Most successful Scrum adoptions have been initiated or driven by an identifiable sponsor,
who is a senior person in the organization responsible for the success of the transition.
The sponsor is also the product owner for the ETC. This means that sometimes an ETC will
have a product owner with little direct experience with Scrum. That’s OK. Like all product
owners, the sponsor of the ETC can fulfil the role by calling on other ETC members for
help. As the ETC’s most senior member, the sponsor will play a significant role in
communicating about the transition effort, but this person does not need to be the sole source
of the vision.

Responsibilities of the ETC

An ETC is a working group. It is not a steering committee. During sprint planning, the ETC
commits to completing some amount of work and demonstrating it at the end of the sprint.
However, even more important than the tangible things the ETC accomplishes is that it
ignites the interest of others. Members of the ETC can only achieve so much themselves.
They will need to rely on others in the company to do most of the work of adopting Scrum
and becoming agile.

The ETC is responsible for the following:

 Articulate the context. Beyond conveying a vision of the organization’s agile future,
the ETC must also help employees both understand the need to change and develop
a desire to change. They do this by articulating the context of the change: Why? Why

Downloaded by Praneeth Varma ([email protected])

 now? Why Scrum? Members of the ETC use their seniority, personal credibility and
more to get others to understand the answers to these questions.
 Stimulate conversation. All sorts of good things happen when people talk. Debating
the merits of various technical practices, sharing success stories, probing reasons for
failure, and other discussions will generate ideas.
 Provide resources. Adopting Scrum will take time, effort, and money. For example,
individuals who are trying to figure out how to be more agile (say, learning how to
write automated unit tests on a complicated code base) may need to be granted time
away from their development projects. Because the ETC includes the most senior
people involved in the transition, the ETC is in a position to ensure that both time
and money are available.
 Set appropriate aspirations. Change efforts with clearly defined and truly
transformational goals are ten times more likely to succeed (McKinsey & Company
2008). The ETC is responsible for setting and communicating appropriate goals for
the transition, which may (and probably should) change over time as the organization
improves. The ETC may establish goals such as moving from one annual release to
quarterly releases, a 50% decrease in post-release defect rate, or so on.
 Engage everyone. Scrum has long tentacles and will reach into many areas of the
organization. The ETC makes sure that the transition effort does not become
narrowly focused on just one group. Within the groups that are affected, broad
participation is encouraged.

Additional Responsibilities
Beyond encouraging people to engage in the transition, the ETC has the following additional
responsibilities:
 Anticipate and address people issues. The ETC should try to anticipate which groups
or individuals are going to struggle the most with the changes brought about by
Scrum and proactively work with them. The cross-functional makeup of the ETC
helps in this regard as it allows the group to see problems from multiple perspectives.
 Anticipate and remove impediments. Members of the ETC are responsible for
removing any organizational impediments to adopting Scrum or doing it well.
Beyond merely removing impediments it is informed of, the ETC should try to
anticipate obstacles and remove them before they cause problems.
 Encourage a simultaneous focus on practices and principles. Adopting Scrum
involves incorporating new practices and valuing new principles. An organization
cannot adopt the practices without the underlying principles, nor can it adopt the
principles without the practices. An effective ETC looks for imbalances in how each
is being adopted. If one is being accepted faster than the other, the ETC can bring
them back in line by directing conversation, attention, and resources toward the
laggard.

Downloaded by Praneeth Varma ([email protected])

DEVOPS

DevOps is a methodology in the software development and IT industry. Used as a set of

practices and tools, DevOps integrates and automates the work of software development (Dev)
and IT operations (Ops) as a means for improving and shortening the systems development life
cycle. DevOps is complementary to agile software development; several DevOps aspects came
from the agile way of working.

DEVOPS ARCHITECTURE

1. Build : Without DevOps, the cost of the consumption of the resources was evaluated
based on the pre-defined individual usage with fixed hardware allocation. And with
DevOps, the usage of cloud, sharing of resources comes into the picture, and the build
is dependent upon the user's need, which is a mechanism to control the usage of
resources or capacity.
2. Code : Many good practices such as Git enables the code to be used, which ensures
writing the code for business, helps to track changes, getting notified about the reason
behind the difference in the actual and the expected output, and if necessary reverting
to the original code developed. The code can be appropriately arranged in files, folders,
etc. And they can be reused.
3. Test :The application will be ready for production after testing. In the case of manual
testing, it consumes more time in testing and moving the code to the output. The testing
can be automated, which decreases the time for testing so that the time to deploy the
code to production can be reduced as automating the running of the scripts will remove
many manual steps.
4. Plan :DevOps use Agile methodology to plan the development. With the operations
and development team in sync, it helps in organizing the work to plan accordingly to
increase productivity.
5. Monitor :Continuous monitoring is used to identify any risk of failure. Also, it helps
in tracking the system accurately so that the health of the application can be checked.

Downloaded by Praneeth Varma ([email protected])

 The monitoring becomes more comfortable with services where the log data may get
monitored through many third-party tools such as Splunk.
6. Deploy :Many systems can support the scheduler for automated deployment. The cloud
management platform enables users to capture accurate insights and view the
optimization scenario, analytics on trends by the deployment of dashboards.
7. Operate :DevOps changes the way traditional approach of developing and testing
separately. The teams operate in a collaborative way where both the teams actively
participate throughout the service lifecycle. The operation team interacts with
developers, and they come up with a monitoring plan which serves the IT and business
requirements.
8. Release :Deployment to an environment can be done by automation. But when the
deployment is made to the production environment, it is done by manual triggering.
Many processes involved in release management commonly used to do the deployment
in the production environment manually to lessen the impact on the customers.

Key features of DevOps architecture is:

 Automation : Automation helps to reduce time during the testing and deployment
phase. With automation, productivity increases, and releases are made faster. This
helps in catching bugs quickly so that they can be fixed easily. For continuous
delivery, each code drop is defined through automated tests, cloud-based services,
and builds. The builds are deployed in production using automation, to reduce
human errors caused due to manual deployment.
 Collaboration : DevOps is a collaboration of the Development and Operations
team. It improves the working model of the teams and they become more productive
with their productivity, which strengthens accountability and ownership. The teams
work in close collaboration sharing responsibilities, which in turn makes the
deployment to production faster.
 Integration :Software Applications need to be integrated with other components in
the environment. The integration phase is where the existing code is

Downloaded by Praneeth Varma ([email protected])

 combined/merged with new features/functionality and then tested. Continuous
integration and testing enable continuous development. A significant operational
challenge is faced in how frequently the releases are to be made. To cater to such
problems, continuous integration and delivery are implemented. It ensures quicker,
safer, and reliable deliveries.
 Configuration management : Configuration management helps in building robust
and stable systems for the engineering teams using tools that can automatically
manage and monitor updates to the configuration data. The configuration file can
be written during deployment(for the automated environment), or it can be loaded
at the run time(manually), depending on the environment in which it is running.

Benefits of DevOps Architecture

DevOps Architecture has many benefits, including reduced cost, better productivity, satisfied
customers, swift releases of products. Here are the top benefits of DevOps architecture :
 Reduced Cost : DevOps helps to reduce the entire cost that involves development
and production. By adopting DevOps a firm can easily cut down their expenses.
 Increased Productivity and Release Time : DevOps eliminated the clashes between
the development team and the operations team. The burden and backlogs were often
used to deteriorate productivity. But with the assistance of DevOps, there has been a
rapid increase in productivity rate and release time.
 Customers Are Served :This is customer-centric software. DevOps collected real-
life data and feedback to enhance customer service.
 It Gets More Efficient with Time :Traditional methods are used to make the entire
procedure complicated. But DevOps Architecture makes the development lifecycle
and gathering requirements easier. This enhances efficiency as gathering
requirements is one of the crucial processes of DevOps. Gathering requirements is a
team effort that can be achieved only with accountability, transparency, and
alliance.
 Improved User Experience :Customer Experience and feedback are crucial.
Organizations work to improvise themselves and upgrade this experience. In this
scenario, DevOps Architecture works as a savior. It enlists insight for each customer
and tries to assist them.
 Faster Software Release :The traditional method would not allow rapid software
release. Whereas, with the assistance of DevOps latest software can be launched and
updated rapidly.
 Stabilized Work Environment :DevOps offers a stabilized work environment by
eliminating bugs, reducing feature updates, and launching recent functions. This
helps to enhance the productivity of developers as well.
 More Room for Innovation :DevOps can instantly acknowledge and fix problems,
unlike traditional methods. DevOps team can constantly examine software and
outline new ideas with the help of DevOps automation.
 Higher Productivity :Higher productivity is possible when the two teams can
communicate and work with an emphasis in their arena. By adopting DevOps,

Downloaded by Praneeth Varma ([email protected])

 organizational silos can be evicted, and that will lead to a sheer growth in
productivity.

DEVOPS DEPLOYMENT:
Deployment strategies define how you want to deliver your software. Organizations follow
different deployment strategies based on their business model. Some choose to deliver software
that is fully tested, and others might want their users to provide feedback and let their users
evaluate under development features (such as Beta releases). The following section discusses
various deployment strategies.

a) In-place deployments
b) Blue/green deployment
c) Canary deployment
d) Linear deployment
e) All-at-once deployment

a) In-place deployments
In this strategy, the previous version of the application on each compute resource is
stopped, the latest application is installed, and the new version of the application is
started and validated. This allows application deployments to proceed with minimal
disturbance to underlying infrastructure. With an in-place deployment, you can deploy
your application without creating new infrastructure; however, the availability of your
application can be affected during these deployments. This approach also minimizes
infrastructure costs and management overhead associated with creating new resources.
You can use a load balancer so that each instance is deregistered during its deployment
and then restored to service after the deployment is complete. In-place deployments can
be all-at-once, assuming a service outage, or done as a rolling update.

b) Blue/green deployment
Blue/green deployment, sometimes referred to as red/black deployment, is a technique
for releasing applications by shift traffic between two identical environments running
differing versions of the application. Blue/green deployment helps you minimize
downtime during application updates, mitigating risks surrounding downtime and
rollback functionality.
Blue/green deployments enable you to launch a new version (green) of your application
alongside the old version (blue), and monitor and test the new version before you
reroute traffic to it, rolling back on issue detection.

Downloaded by Praneeth Varma ([email protected])

 c) Canary deployment
The purpose of a canary deployment is to reduce the risk of deploying a new version
that impacts the workload. The method will incrementally deploy the new version,
making it visible to new users in a slow fashion. As you gain confidence in the
deployment, you will deploy it to replace the current version in its entirety.
Implement Canary Deployment
 Use a router or load balancer that allows you to send a small percentage of users
to the new version.
 Use a dimension on your KPIs to indicate which version is reporting the metrics.
 Use the metric to measure the success of the deployment; this indicates whether
the deployment should continue or roll back.
 Increase the load on the new version until either all users are on the new version
or you have fully rolled back.

d) Linear deployment
Linear deployment means traffic is shifted in equal increments with an equal number
of minutes between each increment. You can choose from predefined linear options
that specify the percentage of traffic shifted in each increment and the number of
minutes between each increment.

e) All-at-once deployment
All-at-once deployment means all traffic is shifted from the original environment to the
replacement environment all at once.

Best DevOps deployment tools:

a) Capistrano
It is an open-source tool that works best on multiple servers for the execution of
arbitrary tasks. It is written in the Ruby language.
Cost price: Free
Advantages:
 Reliable deployment
 Easy setup and automation.
 Simplify general tasks in software teams.
 Encapsulate drive infrastructures.
Companies using Capistrano: Typeforum, New Relic, Tilt, Repro, Qiita.
b) Juju
It is an open-source management tool that decreases operational overhead by
performing various tasks in public and private clouds.
Cost price: Free

Downloaded by Praneeth Varma ([email protected])

 Advantages:
 The fastest way to deploy open stack Cloud.
 users get service configurations as per their needs.
 No dependency problems.
 Offers environment portability.
 Ensures a GUI-based tool and a command line.
 Offers control on scalability.
Companies using Juju: SparkCognition, LabCorp, Lenovo, IBM, ARM, Veritas
Technologies.
c) Travis CI
It is an open-source continuous integration tool that offers the advantage of
building and testing applications on GitHub.
Cost price: Free for open source projects. Chargeable for private projects.
Advantages:
 Easy to build and maintain.
 Effective integration with GitHub.
 Offers a great UI and dashboard.
 Provides vendors with built-in support.
Companies using Travis CI: Govini, Idea Evolver, Emogi, Baker Hughes, Cvent,
Mendal.ai.
d) GoCD
It is an open-source application used for continuous delivery and automation across
various teams within an organization which completes the whole process from
building to deployment.
Cost Price: Free
Advantages:
 Quick configuration with a sequential execution.
 Easy extraction of templates.
 Provides built-in test examination.
 Offers easy visualization and reliable UI.
Companies using GoCD: Hazeorid, OpenX, Xola, ThoughtWorks, Omnifone,
Feedzai.
e) Jenkins
It is a world-famous open-source automation server that is put down in Java. It is a
server-based system that contains multiple dashboards.
Cost price: Free

Downloaded by Praneeth Varma ([email protected])

 Advantages:
 Offers fast updates with built-in GUI tools.
 Requires less maintenance.
 offers rapid delivery and continuous integration.
 Easy configuration.
 Increased concurrency.
Companies using Jenkins: ADP, Wells Fargo, Bank of America, JPMorgan,
American Express.
f) Octopus Deploy
It is a management server that deals with automation deployment and releases. It is
compatible with databases.
Cost price: Free for small teams. Chargeable for large teams.
Advantages:
 Deployments are repeatable and reliable.
 Support changes.
 Flexible integration abilities across platforms.
 Provides a simple UI.
Companies using Octopus Deploy: GM Financial, CIMA, Parexel, AMETEK, ACA
Compliance Group.
g) IBM UrbanCode Deploy
It is used for on-premise distribution and deployment of applications. It can also be
attached to Cloud environments.
Cost price: Chargeable according to subscription plans.
Advantages:
 Offers deployment of applications through data centers.
 Comes with a plugin ecosystem.
 Simple drag and drop process.
 Capable of tracking user activity.
Companies using IBM UrbanCode Deploy: PNC, Analog Devices, Blue Cross Blue
Shield, Amica Mutual Insurance, Huntington.
h) AWS CodeDeploy
It is a tool that is automated and works for deployment that is exclusively offered
by Amazon. It is used for releasing new features without any Hassle.
Cost price: Free for Amazon E2C instances. Chargeable for team-based on-premise
instances.

Downloaded by Praneeth Varma ([email protected])

 Advantages:
 Reliable and faster deployments.
 Applications are easy to launch and track.
 Decreases downtime and increases application availability.
 Easily adapt to other applications.
Companies using AWS CodeDeploy: Algorithmia, Indica, Hello Labs, Adsia,
Zugata, Eventtus.
i) DeployBot
It is used for building connections with any Git Repository so that automatic or
manual deployments can take place. It can also be deployed through Slack.
Cost price: Basic plan- $15. Plus plan- $25. Premium plan- $50.
Advantages:
 Allows execution and compilation of codes.
 Offers various update features.
 Monitors the deployment process.
 It can automatically search for keywords.
Companies using DeployBot: Sellsuki, Edify, Kiwi, Millstream, Kasper systems.
j) Shippable
It is a DevOps tool for continuous delivery. It is associated with docker pipelines
for continuous integration and quick delivery. It also supports multi-tier
applications.
Cost price: Free for one job. Chargeable for additional jobs( public and private
projects).
Advantages:
 The complete process, from building to deployment.
 Easy configuration.
 Separate pipelines for separate code repositories.
 Multiple runtimes are allowed.
Companies using Shippable: Clean Harbors, Worldpay, Wayfair, Stericycle,
Booklt.

ORCHRESTATION

Coordinating the execution of multiple steps in a more complex workflow or pipeline.

Orchestration leverages DevOps tools that allow for rapid updates and releases, version control,
and other best practices for software engineering.

Downloaded by Praneeth Varma ([email protected])

DevOps orchestration tames the complexity of DevOps toolchains by automatically managing
workflows and dependencies in DevOps workflows.
DevOps orchestration allows for more consistent, reliable operations by coordinating the
various automation scripts and procedures that the organisation have developed.

NEED FOR DEVOPS

Business Benefits of DevOps

Adoption of DevOps practices offers varied benefits to the different stakeholders within the
organization including the development team, IT operations staff, and business owners.
It is only natural for the business owners to want to ensure that the time and efforts invested in
implementing DevOps within their organization bring about quantifiable business
returns, Here are the key business benefits of adopting a DevOps Strategy for your
organization.
1) Faster software development cycle
2) Improved interoperability among the teams
3) Continuous releases and deployments
4) Early defect detection leading to quality software development
5) Improved customer experience and greater customer satisfaction
6) Increased productivity as a result of streamlined business processes
7) Fostering innovation within the organization
8) Greater employee satisfaction

1. Improved interoperability among the teams

DevOps adoption results in breaking down of the silos in which the development and
business operations teams traditionally operate in. It improves the interaction between the
different teams, promotes interoperability and results in a culture of transparency that stems
from the collaboration between the different team members.
DevOps allows the IT and business teams to work together collaboratively resulting in
shorter feedback loops and higher business growth. Because of the interoperability
facilitated by DevOps, the development efforts run in direct synchronization with the
business goals.
2. Faster software development cycle
The biggest advantage of DevOps adoption to the business is the incorporation of agility.
The software development cycles are shortened resulting in an enhanced ability for
incorporating changes.
The speed to market is an important consideration while developing a software product in
order to avoid being outpaced by the competitors. The faster development cycle ensures
that the deployment of the product is accelerated while also ensuring faster correction of
errors and bugs.
Use of DevOps tools and processes not only ensures higher development speeds resulting
in faster delivery, it also ensures that the business processes are following the optimal
direction, directly contributing to business success and increased ROI.
3. Continuous releases and deployments
Following the continuous integration and continuous delivery approach of DevOps, the
actual deployment of the software speeds up considerably. The development process
consists of shorter development cycles resulting in faster release of the code into

Downloaded by Praneeth Varma ([email protected])

production. Synchronization of the production cycles with the IT infrastructure also results
in improved efficiency.
Another important advantage of DevOps adoption is the incorporation of automation into
the organization’s development workflow. Automated testing not only speeds up the
development, but it also improves the efficiency of the development process which allows
for the incorporation of more innovative techniques as well as flexibility.
4. Early defect detection leading to quality software development
Defects in the software are the biggest threat to your application. DevOps facilitates early
detection of defects in the code and their subsequent resolution at a significantly faster rate,
resulting in improvement in the overall quality of software.
Collaboration and communication between the different stakeholders, modular
programming and iterative development result in the development of a software product
that is stable and of enhanced quality.
The collaborative DevOps environment fosters a culture of knowledge sharing across the
teams. The automated, continuous monitoring and continuous testing of the code help
improve the overall build quality. Teams are empowered to share their feedback with each
other so that the defects are detected early as well as resolved early.
Since the business side does not have to wait for the incorporation of the feedback received
and changes being made on a shorter notice, more stringent quality control measures can
be implemented resulting in a product that provides an enhanced user experience.
5. Improved customer experience and consumer satisfaction
When the development is better and takes place at a faster rate, customer satisfaction
naturally peaks. DevOps team can better serve the customers, incorporate the customer
feedback in the future product iterations faster, leading to increased customer satisfaction.
DevOps results in increased agility and efficiency responding to their customer needs both
proactively, as well as reactively. A satisfied and engaged customer base is directly related
to improved return on investment and higher business gains.
6. Increased productivity as a result of streamlined business processes
The traditional waterfall method of software development involved handoffs of the
software from one team to another. This increased the chances of error and slowed down
the development process. The advantage with DevOps is that the collaboration among the
different teams streamlines the business process. Real-time changes to the code can be
incorporated and issues and opportunities can be identified at an earlier stage.
The quick incorporation of changes results in low application downtime while boosting the
productivity of all the stakeholders involved in the development process. It encourages
working together and working fast bringing in efficiency in the software development life
cycle.
7. Fostering innovation within the organization
DevOps results in streamlining of processes, more efficient releases, and ensures quality
builds. As the deployment phases are more relaxed, the teams are better rested, and there
is immense scope for bringing an innovative approach for resolving issues.
DevOps makes it possible for teams to foster innovation and creativity resulting in happier,
engaged and a more productive workforce. Automated deployments and standardized
production environments, key aspects of the DevOps model, make deployments predictable
and free people from routine repetitive tasks to go do more creative things.
8. Improved collaboration leading to employee satisfaction
A smoother and more transparent business process that promotes collaboration among the
team members directly results in a happier workplace. The better the team communicates
and collaborates, the greater is their efficiency and work satisfaction.

Downloaded by Praneeth Varma ([email protected])

 Fostering a positive work atmosphere boosts employee morale. Every team member is
equally responsible for contributing to the continuous delivery chain which effectively
empowers the entire team. This results in a culture of trust among the team where every
individual is motivated resulting in a better output that meets the quality expectations which
is delivered in a timely manner and boosts the business growth.

INSTANCE OF APPLICATIONS or APPLICATIONS OF DEVOPS

Real-life Applications of DevOps
 Application of DevOps in the Online Financial Trading Company
The methodology in the process of testing, building, and development was automated
in the financial trading company. Using the DevOps, deployment was being done within
45 seconds. These deployments used to take long nights and weekends for the
employees. The time of the overall process reduced and the interest of clients increased.
 Use of DevOps in Network cycling
Deployment, testing and rapid designing became ten times faster. It became effortless
for the telco service provider to add patches of security every day, which used to be
done only every three months. Through deployment and design, the new version of
network cycling was being rolled out.
 Application in Car Manufacturing Industries
Using DevOps, employees helped car manufacturers to catch the error while scaling the
production, which was not possible before.
 Benefits to Airlines Industries
With the benefit of DevOps, United Airlines saved $500,000 by changing to continuous
testing standards. It also increased its coverage of code by 85%.
 Application to GM Financial
Regression testing time was reduced by 93%, which in turn reduced the funding period
of load by five times.
 Bug Reduction Benefit of DevOps
DevOps has reduced the bugs by up to 35% and in many cases of pre-production bugs
up to 40%. By using DevOps, Rabobank was able to provide better quality applications
for their clients within less time because it massively reduced the time taken for
regression testing.
 Less Time for Integration
Key Bank used DevOps to reduce the time taken for the integration of security and
compliance into the process from 3 months to 1 week.
 Decreased Computation Cost and Operation Time
By the use of DevOps, Computation time has been dramatically reduced. In many cases,
it has reduced the computing time from up to 60%. When the time taken to complete a
task is decreased, then the cost involved the process also decreases.

Downloaded by Praneeth Varma ([email protected])

  Faster Development of Software
The DevOps helps in the faster delivery of apps because it ensures speedier delivery.
 Improvement in Team Collaboration
Transparency is required for better decision-making and works better efficiency of
resources. By using DevOps, teams can be more transparent in their work of developing
applications and software. There are many big tasks of a project which are broken down
into many small tasks that are allotted to different teams or people in the organisation.

DEVOPS PIPELINE

A DevOps pipeline is a set of automated processes and tools that allows developers and
operations professionals to collaborate on building and deploying code to a production
environment.

What is the DevOps pipeline?

A DevOps pipeline is a set of automated processes and tools that allows both developers and
operations professionals to work cohesively to build and deploy code to a production
environment. While a DevOps pipeline can differ by organization, it typically includes
build automation/continuous integration, automation testing, validation, and reporting. It may
also include one or more manual gates that require human intervention before code is allowed
to proceed.
Continuous is a differentiated characteristic of a DevOps pipeline. This includes continuous
integration, continuous delivery/deployment (CI/CD), continuous feedback, and continuous
operations. Instead of one-off tests or scheduled deployments, each function occurs on an
ongoing basis.

Components of a DevOps pipeline

1. Continuous integration/continuous delivery/deployment (CI/CD)
 Continuous integration is the practice of making frequent commits to a common
source code repository. It’s continuously integrating code changes into existing code
base so that any conflicts between different developer’s code changes are quickly
identified and relatively easy to remediate. This practice is critically important to
increasing deployment efficiency.

 Continuous delivery ensures that the “main” or “trunk” branch of an application's

source code is always in a releasable state. In other words, if management came to
your desk at 4:30 PM on a Friday and said, “We need the latest version released right
now,” that version could be deployed with the push of a button and without fear of
failure.

 Continuous deployment entails having a level of continuous testing and operations

that is so robust, new versions of software are validated and deployed into a
production environment without requiring any human intervention.

Downloaded by Praneeth Varma ([email protected])

This is rare and, in most cases, unnecessary. It is typically only the unicorn businesses who
have hundreds or thousands of developers and have many releases each day that require, or
even want to have, this level of automation.

To simplify the difference between continuous delivery and continuous deployment, think of
delivery as the FedEx person handing you a box, and deployment as you opening that box
and using what’s inside. If a change to the product is required between the time you receive
the box and when you open it, the manufacturer is in trouble!

2. Continuous feedback
The single biggest pain point of the old waterfall method of software development — and
consequently why agile methodologies were designed — was the lack of timely feedback.
When new features took months or years to go from idea to implementation, it was almost
guaranteed that the end result would be something other than what the customer expected
or wanted. Agile succeeded in ensuring that developers received faster feedback from
stakeholders. Now with DevOps, developers receive continuous feedback not not only
from stakeholders, but from systematic testing and monitoring of their code in the
pipeline.
 Continuous testing is a critical component of every DevOps pipeline and one of the
primary enablers of continuous feedback. In a DevOps process, changes move
continuously from development to testing to deployment, which leads not only to
faster releases, but a higher quality product. This means having automated tests
throughout your pipeline, including unit tests that run on every build change, smoke
tests, functional tests, and end-to-end tests.
 Continuous monitoring is another important component of continuous feedback. A
DevOps approach entails using continuous monitoring in the staging, testing, and
even development environments. It is sometimes useful to monitor pre-production
environments for anomalous behavior, but in general this is an approach used to
continuously assess the health and performance of applications in production.

Numerous tools and services exist to provide this functionality, and this may involve
anything from monitoring your on-premise or cloud infrastructure such as server resources,
networking, etc. or the performance of your application or its API interfaces.

3. Continuous operations
 Continuous operations is a relatively new and less common term, and definitions
vary. One way to interpret it is as “continuous uptime”. For example in the case of a
blue/green deployment strategy in which you have two separate production
environments, one that is “blue” (publicly accessible) and one that is “green” (not
publicly accessible). In this situation, new code would be deployed to the green
environment, and when it was confirmed to be functional then a switch would be
flipped (usually on a load-balancer) and traffic would switch from the “blue” system
to the “green” system. The result is no downtime for the end-users.

Another way to think of Continuous operations is as continuous alerting. This is the notion
that engineering staff is on-call and notified if any performance anomalies in the application
or infrastructure occur. In most cases, continuous alerting goes hand in hand with continuous
monitoring.

Downloaded by Praneeth Varma ([email protected])

DEVOPS ECO SYSTEM
Following are some of the key components of the DevOps ecosystem:

1. Continuous Integration (CI) and Continuous Delivery (CD) Tools: These tools
automate the build, test, and deployment processes, helping to ensure that changes to
the code are quickly and reliably integrated into the main codebase and deployed to
production.

2. Version Control Tools: These tools, such as Git, help teams manage changes to code,
collaborate more effectively, and track the history of code changes.

3. Infrastructure as Code (IaC) Tools: These tools, such as Terraform or

CloudFormation, enable the creation and management of infrastructure using code,
allowing for more consistent and repeatable infrastructure deployments.

4. Monitoring and Analytics Tools: These tools enable teams to monitor the health of
their systems and applications, detect and diagnose issues quickly, and gain insights
into how their software is being used.

5. Collaboration Tools: These tools, such as Slack or Microsoft Teams, enable teams to
communicate and collaborate effectively, improving productivity and team morale.

6. Agile Methodologies: These methodologies, such as Scrum or Kanban, help teams

work together more efficiently and effectively, delivering value to customers more
quickly and with higher quality.

7. Culture and People: DevOps is not just about tools and technologies; it is also about
people and culture. Building a culture of collaboration, continuous improvement, and
trust is critical to the success of any DevOps initiative.

8. Security and Compliance: DevOps teams must also consider security and compliance
as they build and deploy software. Tools and processes that enable secure development
and deployment are critical to ensuring the safety and privacy of users and customers.

9. Training and Education: Continuous learning and improvement are essential to the
success of any DevOps initiative. Providing training and education to team members
helps ensure that they have the knowledge and skills needed to succeed in a fast-paced,
rapidly-evolving environment.

DEVOPS ADOPTION IN PROJECTS: TECHNOLOGY ASPECTS

Following parameters are needed for implementing DevOps in the workforce:

 Adopting a DevOps culture: Progressive Collaboration DevOps promises to bridge

the gap between the two where both employ bottom-up and top-down feedback from
each other. With DevOps, when development seeks operational help or when operations

Downloaded by Praneeth Varma ([email protected])

 require immediate development, both remain ready for each other at any given time. In
such a scenario, the software development culture brings in to focus combined
development instead of individual goals; The development environment becomes
more progressive as all the team members work in cohesion towards a common goal.
 Processing Acceleration : With conjoined operational and developmental paradigms,
the communication lag between the two is reduced to null. Organizations continuously
strive for a better edge over their competing rivals, and if such acceleration is not
achieved, the organization will have to succumb to competing forces— innovation
will be slower, and the product market will decay.
 Shorter Recovery Time : DevOps deployment functions on a more focused and
exclusive approach which makes issues more accessible to spot; this helps error
rectification faster and easier to implement. The resolution to problems is inherently
quicker, as troubleshooting happens to take place at the current development level only,
within a single team. Thus, the overall time for recovery and rectification is drastically
reduced.
 Lower Failure Rate : The abridged departments yield shorter development cycles
which result in rapid production. The entire process becomes modular wherein issues
related to configuration, application code, and infrastructure become more apparent and
pre-accessible A decrease in error count also positively affects the success rates of
development. Therefore, very few fixes will be required to attain a fully functional code
for the desired output.
 Higher Job Satisfaction : DevOps fosters equality by bringing different officials at
the same level of interaction. DevOps serves as a handy tool for achieving that feat;
it enables the workforce to work in cohesion where chances for failure are minimal,
and production is rapid. As a result, the processing becomes efficient and workspace
more promising.

Technology challenges
 Lack of automation in the software development lifecycle and hence loss of quality
due to error prone repeatability of steps (ex. Tests)
 Defects generated due to inconsistent environments for testing and deployment
 Delays in testing due to infrastructure unavailability
 Brittle point-to-point integration between modules

AGILING CAPABILITIES
Both, Agile and DevOps methodologies complement each other and thus can work in
tandem.
 Agile rapidly adapts to changing requirements while collaborating better between the
smaller teams
 DevOps enables continuous automated integration and deployment to enable frequent
releases while collaborating better between the smaller teams.
 When applied in tandem, Agile DevOps enables significantly faster development and
deployment while keeping the customer’s needs at the forefront. Continuous feedback
and integration become quicker and easier.

Downloaded by Praneeth Varma ([email protected])

TOOL STACK IMPLEMETATION

Tool stack and its implementation Now that the capabilities are understood, let us look
at how to use tools to actionize the capabilities in the team he aim of choosing the tool
stack is to build an automated pipeline using tools for performing the various software
development, testing, deployment and release activities. This helps in creating rapid,
reliable and repeated releases of working software with low risk and minimal manual overhead.
Here are the principles to be considered while choosing tools.

Principles to be considered
 Repeatability : The automated pipeline needs to be executed frequently and multiple
times with consistency
 Reliability : The automated pipeline should ensure reliable software
 End to end automation : The activities from coding to release should be automated
 100% source control : All the artifacts involved in the pipeline need to be
version controlled (ex. Source code, automated test cases, reports, binaries etc.)
 Auto build quality : Pipeline should have quality auto-built by way of gating
conditions
 Done is released : Pipeline should ensure that “done-ness” as per the definition of done
is only released to production
 Continuous feedback : Tools provide continuous feedback by way of reports
 Customer appetite for tooling : The availability of budget from customer, existing
tools and alliances, technology used in the project, feasibility of automation

The tools stacks are evolving and there are many vendors in this area. Practical tips
 Tooling is a consulting exercise. The DevOps and Lean coach suggests using the Java
and open source stack for the system development at "Project" for the reasons
mentioned below.
 Reasons
 The tools involved in this stack are primarily open source, free and powerful
 The project is an application development project using Java stack
 Quick availability of these tools and no overhead of maintenance of licenses

The team is advised to get the OSS (Open Source Software) compliance for the open source
tools prior to the installation. OSS compliance refers to the compliance in terms of
using approved and supported source code.
There should be a policy and process to check the usage, purchase (as all open source software
is not free), management and compliance(some can be used for training but payment is required
if used commercially).Tools like Black Duck help in checking OSS compliance.

Some of the tools used in DevOps are listed below:

1. Puppet
Puppet is the most widely used DevOps tool. It allows the delivery and release of the
technology changes quickly and frequently. It has features of versioning, automated testing,
and continuous delivery. It enables to manage entire infrastructure as code without
expanding the size of the team.

Downloaded by Praneeth Varma ([email protected])

Features
 Real-time context-aware reporting.
 Model and manage the entire environment.
 Defined and continually enforce infrastructure.
 Desired state conflict detection and remediation.
 It inspects and reports on packages running across the infrastructure.
 It eliminates manual work for the software delivery process.
 It helps the developer to deliver great software quickly.
2. Ansible
Ansible is a leading DevOps tool. Ansible is an open-source IT engine that automates
application deployment, cloud provisioning, intra service orchestration, and other IT
tools. It makes it easier for DevOps teams to scale automation and speed up
productivity.
Ansible is easy to deploy because it does not use
any agents or custom security infrastructure on the client-side, and by pushing
modules to the clients. These modules are executed locally on the client-side, and the
output is pushed back to the Ansible server.
Features
 It is easy to use to open source deploy applications.
 It helps in avoiding complexity in the software development process.
 It eliminates repetitive tasks.
 It manages complex deployments and speeds up the development process.
3. Docker
Docker is a high-end DevOps tool that allows building, ship, and run distributed
applications on multiple systems. It also helps to assemble the apps quickly from the
components, and it is typically suitable for container management.
Features
 It configures the system more comfortable and faster.
 It increases productivity.
 It provides containers that are used to run the application in an isolated
environment.
 It routes the incoming request for published ports on available nodes to an
active container. This feature enables the connection even if there is no task
running on the node.
 It allows saving secrets into the swarm itself.
4. Nagios
Nagios is one of the more useful tools for DevOps. It can determine the errors and
rectify them with the help of network, infrastructure, server, and log monitoring
systems.
Features
 It provides complete monitoring of desktop and server operating systems.
 The network analyzer helps to identify bottlenecks and optimize bandwidth
utilization.
 It helps to monitor components such as services, application, OS, and network
protocol.
 It also provides to complete monitoring of Java Management Extensions.

Downloaded by Praneeth Varma ([email protected])

5. CHEF
A chef is a useful tool for achieving scale, speed, and consistency. The chef is a cloud-
based system and open source technology. This technology uses Ruby encoding to
develop essential building blocks such as recipes and cookbooks. The chef is used in
infrastructure automation and helps in reducing manual and repetitive tasks for
infrastructure management.
Chef has got its convention for different building blocks, which are required to manage
and automate infrastructure.
Features
 It maintains high availability.
 It can manage multiple cloud environments.
 It uses popular Ruby language to create a domain-specific language.
 The chef does not make any assumptions about the current status of the node.
It uses its mechanism to get the current state of the machine.
6. Jenkins
Jenkins is a DevOps tool for monitoring the execution of repeated tasks. Jenkins is a
software that allows continuous integration. Jenkins will be installed on a server where
the central build will take place. It helps to integrate project changes more efficiently
by finding the issues quickly.
Features
 Jenkins increases the scale of automation.
 It can easily set up and configure via a web interface.
 It can distribute the tasks across multiple machines, thereby increasing
concurrency.
 It supports continuous integration and continuous delivery.
 It offers 400 plugins to support the building and testing any project virtually.
 It requires little maintenance and has a built-in GUI tool for easy updates.
7. Git
Git is an open-source distributed version control system that is freely available for
everyone. It is designed to handle minor to major projects with speed and efficiency. It
is developed to co-ordinate the work among programmers. The version control allows
you to track and work together with your team members at the same workspace. It is
used as a critical distributed version-control for the DevOps tool.
Features
 It is a free open source tool.
 It allows distributed development.
 It supports the pull request.
 It enables a faster release cycle.
 Git is very scalable.
 It is very secure and completes the tasks very fast.
8. SALTSTACK
Stackify is a lightweight DevOps tool. It shows real-time error queries, logs, and more
directly into the workstation. SALTSTACK is an ideal solution for intelligent
orchestration for the software-defined data center.
Features
 It eliminates messy configuration or data changes.
 It can trace detail of all the types of the web request.

Downloaded by Praneeth Varma ([email protected])

  It allows us to find and fix the bugs before production.
 It provides secure access and configures image caches.
 It secures multi-tenancy with granular role-based access control.
 Flexible image management with a private registry to store and manage
images.
9. Splunk
Splunk is a tool to make machine data usable, accessible, and valuable to everyone. It
delivers operational intelligence to DevOps teams. It helps companies to be more
secure, productive, and competitive.
Features
 It has the next-generation monitoring and analytics solution.
 It delivers a single, unified view of different IT services.
 Extend the Splunk platform with purpose-built solutions for security.
 Data drive analytics with actionable insight.
10. Selenium
Selenium is a portable software testing framework for web applications. It provides an
easy interface for developing automated tests.
Features
 It is a free open source tool.
 It supports multiplatform for testing, such as Android and ios.
 It is easy to build a keyword-driven framework for a WebDriver.
 It creates robust browser-based regression automation suites and tests.

PEOPLE ASPECT

DevOps has direct positive effects to our experience as humans working with technology.
3 specific areas in which DevOps has direct, positive effects on our experiences as human
operators of software systems:
 Reduced stress and anxiety
 Offloading mind-numbing, repetitive work
 Increasing collaboration and trust
1. Reduced Stress & Anxiety
One of the universal, shared experiences of folks in IT Development & Operations is
the pain of pushing out software to production. The stress around software
deployments, the pressure to make the right decisions on the fly, to fix issues in the
midst of outages that are costing your company thousands of dollars per hour in lost
revenue, is massive.
This stress is often exacerbated by lack of sleep over deploys that can last days. Once
the deploy is complete and the seemingly inevitable issues are exposed, the feelings of
frustration and dread as blame is assigned and decisions are cross-examined is truly
horrible. Such repeated experiences are a major contributor to engineer burnout.
DevOps addresses this IT pain point. DevOps makes software delivery a routine,
practiced, controlled event, with robust tests and automation to minimize human
involvement – in contrast to the traditional “big bang” deploys where the expectation
of “all hands on deck!” is the norm.
Of course, DevOps does not eliminate this stress instantly or completely – but it does
provide a path forward that if embraced, can provide substantial relief in this area. The
phrase “if it hurts, do it more often” is a DevOps mantra capturing this idea.

Downloaded by Praneeth Varma ([email protected])

 2. Offloading Mind-numbing, Repetitive Work
Another central idea behind DevOps is the drive eliminate repetitive, error-prone
manual work within the software value stream. Unnecessary human intervention in a
software delivery stream is a DevOps anti-pattern. “Automate all the things” is how
this concept is captured in the DevOps world.
3. Increasing Collaboration and Trust
DevOps only succeeds in a culture of collaboration across the entire software value
stream. It is impossible to embrace DevOps without fundamentally changing the
traditional team dynamics of operating within silos of “Development”, “Operations”,
“SQA” etc.

Drawbacks or Hardships
 People (DevOps engineers and their managers) are having a hard time keeping up with
the avalanche of new tools and technologies to learn.
 Organizations are having a hard time finding and retaining qualified personnel.

Ideologies to be adopted by organisations to overcome that avalanche

 Hire For the Growth Potential, Not for the Current Skills
Experience and good foundations do matter! However, with the current rate of
knowledge turnover, I’d rather hire a smart, curious, self-driven Junior engineer than
someone who had been writing the same Java applications for the past 10 years.
 Create a Continuous Learning Pipeline
Akin to CI/CD pipelines pushing new features from code commit to production, managers
and organizations need to, can and should create pipelines for training their staff. It is
more cost-effective for organizations to invest time and effort in training existing and
loyal staff than hiring from the market and losing to the market within a year. Learning
Management is one of the most critical functions of a manager in an Agile/DevOps
organization — identifying the strategic new skillsets for the organization and creating the
environment and incentives for their acquisition. The team can take care of the rest.
 Learn on a Kanban
Old CMMI-style Training Management Plans are just as useless as the old-school Project
Management Plans and Business Requirements Documents. A Learning Plan can be as
simple, transparent and effective as a Kanban board with a card for every book, training
class, seminar, conference or training dojo planned for each team member. (I keep a
backlog of books or anything requiring more than 1 hr of reading/research on my
personal Kanban in Asana.) Good organizations set aside training budgets and monitor
the actuals to stay under budget. Better organizations track training and certification
completion and ensure the training budgets are maxed out the most efficient way.
 Embrace MicroLearning
Again, doing as we preach — while we strive to reduce the batch size of our product
deliverables, we should also reduce the batch size and ensure the continuous flow of our
learning. Old-school, 3-day, classroom classes are no longer needed nor they should be
encouraged or accepted by managers. Such classes are expensive, removed from context,
and ineffective. After 3-day-long brain crunch learning something new, one doesn’t
remember what they had for breakfast, let alone what they learned in Chapter 1 three
days ago. I find a lot more effective the new style of low-production-cost, micro-video-

Downloaded by Praneeth Varma ([email protected])

stile training. It is a lot easier to commit 15 minutes here and there than full 3 days.
Content is current because it is so easy and quick to produce. And the subscriptions are
dirt-cheap. The caveat is that one should have the discipline to stay on track and keep
taking the video classes. This can be easily visualized and tracked on the Kanban board
above.
 Yearly Performance Reviews
… are a big pet peeve of mine. They didn’t really work in the past, but they are even
more antiquated now. On one hand, my team and I are working on 2-week sprint
objectives and driving toward daily deployments, but on the other hand, my reports and I
need to come up with yearly goals, and assess them at the end of the year?! That’s too
long of a period in the IT time & space continuum. A talented DevOps engineer can
change jobs twice (with 10–20% salary increase every time) before it is time for the next
Year-End review and promotion conversation. There is a huge disconnect and HR
consultants and organizations need to seriously reconsider this process and embrace
Lean!
 Promote Team Players as Opposed to Individual Star Performers
This is another reason why the typical performance reviews don’t work — they single
out and reward the overachievers on the team, as opposed to promoting the teamwork
and collaboration so essential for DevOps. There will always be people who try harder
and work smarter, and we as managers should, absolutely, reward them! However, as
additional performance objectives for everyone regardless of seniority, we should have
metrics for knowledge sharing, experimentation, new ideas, learning, and acquisition of
new skills.
 Groom Generalists as Opposed to Specialists
Agile has been preaching for a long time having “teams of multi-functional generalists”.
I have never seen a person who is equally diligent and detail-oriented for business
analysis work, as skilled in coding, and patient for testing. People naturally gravitate
toward a particular skillset, with which comes the superficial label — “BA”,
“Developer”, or “Tester”. This is even more challenging in DevOps where people who
used to know hardware, operating systems, subnets and reverse proxies, now need to
know code (beyond the shell scripting) and vice versa. The learning curve is a lot steeper.
One of the best ways for a Manager to work around it is to periodically rotate team
members and change their roles and responsibilities. (Referring you back to the
Continuous Learning Pipeline section above.) It builds both knowledge and empathy. A
developer carrying a pager for 1 month will write a lot better code afterward, and an Ops
engineer reviewing a pull request will have a lot better understanding of the next
deployment impact in production.

PROCESSES
The key purpose of DevOps is to reach agility in software development. It means that all
processes and stages of the creation and deployment are easily adaptable to changes thanks
to thorough communication and collaboration between the development and operations
departments.

Downloaded by Praneeth Varma ([email protected])

DevOps process flow

DevOps process contains many useful DevOps practices that were developed through years
of implementing DevOps concepts in the software production business. All these developer
operations are aimed to ensure automation, heighten productivity, and provide quick ways of
resolving issues and fixing bugs in the software build processes.

 Continuous Integration
According to this DevOps practice, the developer makes numerous daily modifications
to the shared repository's source code. When even little modifications are made to a
bigger codebase, they get to be tested and reported. Continuous integration (CI) aims
to provide quick feedback so that any flaws can be found and fixed right away.
 Continuous Testing
To get quick input on the business risk connected to software release, continuous testing
is required as one of the DevOps practices. It is a difficult and crucial component of the
software. Testing is a necessity for software rating. Automated testing tools are
utilized because it is simpler to test continually rather than testing a whole piece of
software. The developer uses the test function to balance quality and speed.
 Continuous Delivery
Continuous delivery (CD) is the capability to make adjustments, such as adding new
characteristics and features, managing configurations, fixing bugs, and putting
experiments into production. A continual daily upgrade is our driving force behind
continuous supply. If there is a mistake in the production code at that point, we can easily
repair it. So, here we are quickly, consistently, and with the least amount of overhead
creating and releasing our application.
 Continuous Deployment
As soon as the code successfully completes all test cases, it is promptly deployed to the
manufacturing environment for production. Alternate versions of the code are always

Downloaded by Praneeth Varma ([email protected])

 present in the right places thanks to continuous updating. Continuous deployment many
consider a better variant for IT DevOps production than CD because it doesn’t require
manual work from employees. Every update to the code is automatically deployed with
the help of DevOps deployment tools, leading to several deployments in the production
environment every day.
 Continuous Monitoring
DevOps lifecycle tools include a reporting tool that enables developers and testers to assess
the functionality and performance of their applications before it is implemented in
operations. To reduce the number of errors and changes, continuous monitoring provides
feedback.
 Continuous Development
The iterative process for creating software that will be provided to users is called
"continuous development". Continuous integration, testing, delivery, and deployment are
all components of it. So we can say that continuous development is a sort of umbrella term
for other DevOps basics. Organizations can provide innovative features or goods more
quickly, with lower risk and improved quality, by utilizing a continuous development
strategy and its related sub-strategies, without encountering substantial bandwidth
constraints.

An order of progressive DevOps implementation might resemble this:

1. Adopt an agile development methodology;

2. Utilize cloud computing;
3. Get your procedures in line with a CI and CD workflow;
4. Automate software deployment process flow;
5. Organize automated software testing;
6. Use a continuous deployment DevOps strategy.

The comparison between both models is tabulated as follows -

S.no. Purpose Agile model Waterfall model

1. Definition Agile model follows the incremental Waterfall model follows a
approach, where each incremental part sequential design process.
is developed through iteration after
every timebox.
2. Progress In the agile model, the measurement of In the waterfall model, generally the
progress is in terms of developed and measurement of success is in terms
delivered functionalities. of completed and reviewed artifacts.

Downloaded by Praneeth Varma ([email protected])

 3. Nature Agile model is flexible as there is a On the other hand, the waterfall
possibility of changing the requirements model is rigid as it does not allow to
even after starting the development modify the requirements once the
process. development process starts.
4. Customer In Agile model, there is a high customer Customer interaction in waterfall
interaction interaction. It is because, after every model is very less. It is because, in a
iteration, an incremental version is waterfall model, the product is
deployed to the customer. delivered to the customer after
overall development.
5. Team size It has a small team size. As smaller is In the waterfall model, the team may
the team, the fewer people work on it so consist more members.
that they can move faster.
6. Suitability Agile model is not a suitable model for
Waterfall model works well in
small projects. The expenses of smaller size projects where
developing the small projects using requirements are easily
agile is more than compared to other understandable. But waterfall model
models. is not suitable for developing the
large projects.
7. Test plan The test plan is reviewed after each Test plan is reviewed after complete
sprint. development.
8. Testing Testing team can take part in the It is difficult for the testing team to
requirements change phase without initiate any change in needs.
problems.

Below is a difference between Agile and Waterfall methodologies:

Agile Waterfall
It separates the project development lifecycle Software development process is divided into distinct
into sprints. phases.
It follows an incremental approach Waterfall methodology is a sequential design process.
Agile methodology is known for its Waterfall is a structured software development
flexibility. methodology so most times it can be quite rigid.
Agile can be considered as a collection of Software development will be completed as one
many different projects. single project.
Agile is quite a flexible method which allows There is no scope of changing the requirements once
changes to be made in the project the project development starts.
development requirements even if the initial
planning has been completed.
Agile methodology, follow an iterative All the project development phases like designing,
development approach because of this development, testing, etc. are completed once in the
planning, development, prototyping and other Waterfall model.
software development phases may appear
more than once.
Test plan is reviewed after each sprint The test plan is rarely discussed during the test phase.

Downloaded by Praneeth Varma ([email protected])

 Agile development is a process in which the The method is ideal for projects which have definite
requirements are expected to change and requirements and changes not at all expected.
evolve.
In Agile methodology, testing is performed In this methodology, the “Testing” phase comes after
concurrently with software development. the “Build” phase
Agile introduces a product mindset where the This model shows a project mindset and places its
software product satisfies needs of its end focus completely on accomplishing the project.
customers and changes itself as per the
customer’s demands.
Agile methodology works exceptionally well Reduces risk in the firm fixed price contracts by
with Time & Materials or non-fixed funding. getting risk agreement at the beginning of the process.
It may increase stress in fixed-price scenarios.
Prefers small but dedicated teams with a high Team coordination/synchronization is very limited.
degree of coordination and synchronization.
Products owner with team prepares Business analysis prepares requirements before the
requirements just about every day during a beginning of the project.
project.
Test team can take part in the requirements It is difficult for the test to initiate any change in
change without problems. requirements.
Description of project details can be altered Detail description needs to implement waterfall
anytime during the SDLC process. software development approach.
The Agile Team members are In the waterfall method, the process is always
interchangeable, as a result, they work faster. straightforward so, project manager plays an essential
There is also no need for project managers role during every stage of SDLC.
because the projects are managed by the
entire team

Agile vs Waterfall – Difference Between Methodologies

Key Difference Between Waterfall and Agile
 Waterfall is a Linear Sequential Life Cycle Model, whereas Agile is a continuous
iteration of development and testing in the software development process.
 In Agile vs Waterfall difference, the Agile methodology is known for its flexibility,
whereas Waterfall is a structured software development methodology.
 Comparing the Waterfall methodology vs Agile, which follows an incremental
approach, whereas the Waterfall is a sequential design process.
 Agile performs testing concurrently with software development, whereas in Waterfall
methodology, testing comes after the “Build” phase.
 Agile allows changes in project development requirements, whereas Waterfall has no
scope of changing the requirements once the project development starts.

What is Waterfall methodology?

Waterfall Model methodology which is also known as Linear Sequential Life Cycle Model.
Waterfall Model followed in the sequential order, and so project development team only
moves to next phase of development or testing if the previous step completed successfully.

Downloaded by Praneeth Varma ([email protected])

What is the Agile methodology?
Agile methodology is a practice that helps continuous iteration of development and testing in
the software development process. In this model, development and testing activities are
concurrent, unlike the Waterfall model. This process allows more communication between
customers, developers, managers, and testers.

Advantages of Waterfall Model:

 It is one the easiest model to manage. Because of its nature, each phase has specific
deliverables and a review process.
 It works well for smaller size projects where requirements are easily understandable.
 Faster delivery of the project
 Process and results are well documented.
 Easily adaptable method for shifting teams
 This project management methodology is beneficial to manage dependencies.

Advantages of the Agile Model:

 It is focused client process. So, it makes sure that the client is continuously involved
during every stage.
 Agile teams are extremely motivated and self-organized so it likely to provide a better
result from the development projects.
 Agile software development method assures that quality of the development is
maintained
 The process is completely based on the incremental progress. Therefore, the client and
team know exactly what is complete and what is not. This reduces risk in the
development process.

Limitations of Waterfall Model:

 It is not an ideal model for a large size project
 If the requirement is not clear at the beginning, it is a less effective method.
 Very difficult to move back to makes changes in the previous phases.
 The testing process starts once development is over. Hence, it has high chances of
bugs to be found later in development where they are expensive to fix.

Limitations of Agile Model

 It is not useful method for small development projects.
 It requires an expert to take important decisions in the meeting.
 Cost of implementing an agile method is little more compared to other development
methodologies.
 The project can easily go off track if the project manager is not clear what outcome
he/she wants.

Downloaded by Praneeth Varma ([email protected])