DevOps is a methodology that promotes collaboration between development and operations teams to continuously deliver products or services. It aims to improve efficiency through continuous integration, delivery, infrastructure automation, and monitoring. Some benefits include reduced delays, outdated technology, and profits lost. The journey to DevOps requires breaking down silos, improving communication, and applying its principles through automation and metrics tracking.

1. WHAT CHANGES
CAN A DEVOPS
APPROACH BRING
TO SOFTWARE
DEVELOPMENT?
Mauro Cossu

2. AGENDA
• Defining DevOps
• Anti-Patterns of non DevOps
• Impact to the product
• Continuous Integration
• Continuous delivery
• Infrastructure as code
• Continuous Monitoring and improvement
• Embarking on the DevOps journey
• TopTakeaways

3. A DEFINITION
DevOps is a methodology that promotes collaboration and coordination between developers and
operational teams to deliver products or services in a continuous manner.This approach is very helpful in
organisations where the teams rely on multiple applications, tools, technologies, platforms, databases, and
devices in the process of developing or delivering a product or service.
The goal of the DevOps methodology is a continuous delivery model that is repeatable, reliable,
stable, resilient, and secure, and that improves operational efficiency.

4. ANTI-PATTERNS & PATTERNS
Anti-patterns Patterns
Scheduled builds, nightly builds, building periodically, building exclusively
on developer's machines, not building at all. Run a software build with every change applied to the Repository.
Keeping changes local to development for several days and stacking up
changes until committing all changes.This often causes build failures or
requires complex troubleshooting.
Organize source code changes by task-oriented units of work and
submit changes as a Task-Level Commit.
Continually repeating the same processes with manual builds or partially
automated builds requiring numerous manual configuration activities.
• Automate all activities to build software from a source without
manual configuration.
• Create build scripts that will be executed by a CI system so that
software is built at every change.
•
Sending minimal or too much feedback that provides no insight into the
build failure or is non-actionable.
Send automated feedback from the CI server to development team
members involved in the build.
• Manually running functional tests.
• Manually checking deployment sensitive sections of the project
Create smoke tests that can be used by CI servers, developers, QA,
and testing as a pre-check to confirm the most important
functionality as they work, or before committing resources to a full
build. Fail Fast

5. IMPACTTO PRODUCT
• Delayed releases
• Outdated tech
• Profits lost
• No automated control over
deployment schedule

6. CONTINUOUS INTEGRATION
• Continuous integration is about
merging, building, and testing
code frequently.The practice of
merging code frequently reduces
merge conflicts and avoids
merge hell situations.
• When developers commit and
integrate code frequently, they
have visibility into changes made
by other teams and can detect
and address incompatible
changes early in development.

7. CONTINUOUS DELIVERY
• Continuous delivery and
deployment are the application of
the same principles from continuous
integration to the process of getting
new versions of your software from
integration to release.The emphasis
here is also in using automation to
increase the velocity.
• Externalising these configurations
and tools keeps them consistent
between builds, enables better
automation, and allows your process
to scale

8. WHY USE INFRASTRUCTURE
AS CODE
• Deploy identical infrastructure across all environments including development, QA,
testing, and production setups.
• It also allows you to create production-like setups for testing the code during
development and testing phases.
• Perform frequent testing of the code as the deployment of infrastructure is no longer a
time-consuming, resource-intensive process.
• Deploy and configure the infrastructure at the push of a button and perform your tests
instantaneously.This allows you to fail early and fail fast in case of any discrepancies in
the code and fix it without wasting more time and resources on the faulty code.
• Eliminate delays associated with setting up and configuring infrastructure.

9. JOURNEYTO DEVOPS
• It starts with the breaking down of traditional silos, improving
communication between development and operations teams
and creating new structures and processes.
• A good place to begin is to take a small project, and apply a
new method to the development, test, deploy and remediate
process to retrain the team’s muscles instead of trying to
convert your entire company over to DevOps in one night.
• Need to make sure the people and process changes are
happening in conjunction and give yourself time to assess the
knowledge base and expertise of your team, operational
readiness and experiment with different tools. Consider
training and hiring devops experts.
• Ask questions like
• “How does your software lifecycle look today?”
• “What are we doing for automation today?”
• “What tools are we currently using. Is there cross
functional teamwork going on already?”

10. CONTINUOUS MONITORING
AND IMPROVEMENT
Track various metrics to monitor and improve your DevOps
practice. Examples of DevOps-related metrics are:
- ↑ Change volume: Change volume is the number of user
stories developed, number of lines of new code, and number of
bugs fixed.
- ↑ Deployment frequency: Deployment frequency indicates
how often a team is deploying an application.This metric should
generally remain stable or trend upward.
- ↓ Lead time from development to deployment:The
time between the beginning of a development cycle to the end of
deployment can be used to identify inefficiencies in the
intermediate steps of the release cycle.
- ↓ Percentage of failed deployments:The percentage of
failed deployments, including the number of deployments that
resulted in outages, should be a low number.This metric should be
reviewed in conjunction with the change volume.
- ↑ Availability:Track how many releases caused failures that
possibly resulted in violations of service level agreements (SLAs).
What is the average up-time for the application?
- ↓ Customer ticket volume:The number of tickets filed by
customers is an indicator of the quality of your application.

11. TOPTAKEAWAYS
• Automation.Automation.Automation
• Move towards consolidation and
standardisation in order to drive
automation – and its benefits –
throughout the entire organisation, and
not just in pockets.
• Releasing Bad Code Faster Now?
Testing is one of the toughest things to
automate and is often the Achilles heel
of your pipeline and release processes.
• It’s all about the people, investing in the
people and the training with DevOps 'A
fool with a tool is still a fool'