DevOps is a practice that aims to break down barriers between development and operations teams. It originated as teams adopted Agile methodologies and moved toward continuous delivery of software. DevOps aims to speed up delivery through practices like continuous integration, infrastructure as code, and breaking down silos between teams. The document outlines the history and benefits of DevOps, including increased speed, reliability, collaboration and security. It also defines key DevOps practices and provides examples of how they work.

1. An introduction to what it is, and why
this is indeed your business
DevOps
Andrea Tino (Software Development Engineer)

2. Our journey
The agenda for today
An introduction to DevOps to
understand what they are and
why you need to start
adopting it inside your
organization.
What? We’ll look at where we came
from to understand why
DevOps today arised in the
Industry. Then, we‘ll talk
about DevOps in more details.
How?
We ask ourselves why we have
DevOps today. The question
we will try to answer is: “Why is
DevOps a thing today?”.
Why?
In your business! You will see
DevOps spans across the
entirity of your organization.
Where?
As soon as possible :) Changes
take time, but the sooner you
think about it the better.
When?
Be a startup or an
experienced business: no
matter what, this is for you!
Who?

3. How did we get here?
What happened in the previous episodes...
~780cycles:~442cyclesago ~442cycles:~208cycles ago present : 50+cycles further
1 cycle=1sprint=~2wks
In the past 30 years software has
exponentially spread out in the world
and our lives. The way we make
software started in a way and rapidly
changed. Let’s have a look at the past
to understand the present and
unleash the future.
Long story
made short
We used to build software
in a very monolithic way.
This proved to be
unsustaninable.
Jurassic We basically became
Agile and started
adopting better
methodologies.
Pleistocene We start adopting
continuous everything
and DevOps is our reality
now.
Gen
Alpha?

4. SaaB: Software as a Building
Customer delivers
requirements to the
Architect.
1
Architect makes the design
and delivers blueprints to
the Engineer.
2
Engineer checks
feasibility and delivers
construction schemes
to Build Team.
3
Build Team makes it
happen.
4
When software started
becoming a thing,
engineers and
organizations wondered
about how the
Dev
model
development model had
to be structured.
Structural Engineering
seemed to be an industry
resembling ours, thus we
adopted Waterfall
(Royce) thinking it could
satisfy our needs.
Indeed it did so, but not in
the long run: things
changed quickly.
Software was built like a house:
through a sequence of
forward-only steps/phases.
Waterfall
Software was meant to be used for
specific requirements supposed
not to change in the short term: the
business had slow dynamics.
Business
model

5. The New Methodology
Developers
Customer
High interaction
As customers started
coming back to
developers with more and
more changing
requirements, it was
obvious that Waterfall was
making things slow and
tedious.
Since 1970, different
paradigms started
emerging by promoting
and enforcing lightweight
Dev
model
processes: ASD, RAD
(1991), UP, DSDM(1994),
Scrum (1995), XP (1996)
and more.
The Agile Manifesto was
published later in 2001,
generalizing those new
trending methods focused
on: customer interaction
and continuously
changing software.
Software is now developed
according to (almost all) the 12
principles in the Agile Manifesto.
Agile
process
Requirements change often and
software has to keep up in an really
dynamic environment where
services are highly connected.
Business
model

6. DES
IGN DEV
ELOPTE
ST
REQ
UIRE
Customer
UX Designer
Tester
Developer
TOWARDS AGILE
D
ESIGN
Customer
UX Designer
Tester
Developer
DE
VELOP
TESTRE
QUIRE
As Agile methodologies
started being applied in
the Industry, the
approach to developing
software changed and
Engineering Teams
applied different
Changing
model &
mindset
organizational models.
Before, Teams were
divided according to
development scope:
design, development,
testing, etc. This seloed
configuration
contributed in slowing
down activities and
caused delays when
responding to change.
Now, Teams tend towards
a more unified model
allowing reactions to new
requirements to be
quicker in order to follow
a more dynamical
business model.

7. Now: DevOps
This is how we got here
Development Operations Quality Assurance
DevOps
Consider the
transformation that
teams had to take in
place when adopting
Agile methodologies.
What happened in
Engineering teams, is
now attempted across
the entire
organization, not just
Engineering!
Seloed departments
in the organization like
Development and
Operations are now
merged together.
The
modern
transition

8. OpsDev
dynamic
business innov-
ate
scale
up micro
services
DevOps is a transition
to a different mindset
in general. Its need is
related to the way
business has evolved
today.
Things change often
and the market
demands more
innovation.
Organizations must
keep their products
competitive, and to
respond well, they
need to scale up.
One for
all, and
all for
one
This means adopting
a micro-services
architecture which is
perfectly handled
when DevOps is
implemented across
different Teams.

9. DevOps
Definition
noun
The practice of operations and development engineers
participating together in the entire service lifecycle, from design
through the development process to production support.
somewhere in the Internet
By implementing DevOps,
it is possible to achieve 6
key benefits inside an
organization.
6
Benefits
In order to successfully
implement DevOps, 6
practices can be
implemented.
6
Practices

10. Benefits of DevOps
By adopting the most
common
methodologies in
DevOps, it is possible
to react quickly to
change and effectively
keep up with markets
and demanding
customers.
Speed DevOps takes
advantage of
Continuous
Integration and
Continuous Delivery,
which are well known
and effective practices
to keep software
updated and always
available to customers.
Rapid
delivery
Monitoring and
keeping track of your
applications in the
cloud can help you
detect issues before
they can surface to
customers. Processing
feedback from your
solutions is an
important approach.
Reliabil-
ity
DevOps takes
advantage of
micro-services
oriented architectures
in order to ensure that
solutions in the Cloud
can be scaled up or
down according to
necessities in your
business.
Scaling DevOps’s main
objective is to remove
barriers between two
teams classicaly seen
as seloed:
Development and
Operations. These
methodologies can
boost collaboration in
all organizations.
Collab-
oration
Many common
practices today allow
security to be handled
at different levels
thanks to IaC and PaC,
which allow
organizations to
achieve greater control
over their resources.
Security

11. PLAN
DEVELOP
TEST
PACKAGE
RELEASE
CONFIG/DEPLOY
MONITOR
The build contains all tests ready to be
executed. They are run and results
reported. If green, can move on.
EngineeringTeamsareresponsible
forpreparingthecodechangesfor
implementingnewfeatures.
Lightweight planning defines what
goals are to be reached in the current
iteration, what features to build.
Thecodeispreparedtobe
shipped.Inthisphase,code
signingmightbeapplied.
Packages are published
and delivered to the
customer.
Theproductismadereadyfordeployment
inordertobeexecuted.Thiscanhappen
automaticallyorbymanualprocess.
Telemetry and usage data is
collected to be evaluated in
next iteration.
This is the most famous
image that one can find
on the Internet when
searching for DevOps!
It highlights the two
involved departments
(development and
operations) and how the
different activities are
shared across them.
Furthermore, the
infinity-shaped flow
remarks how the
different tasks are
carried on by the two
Teams together, where
barriers are removed:
work and expertise is
also shared.
The toolchain

12. Practices in DevOps
CI CD MS
MC2IaC
Implement these practices first
Focus on these practices later
DevOps includes 6 important practices:
6 practices
Continuous Integration
Automate builds and tests
by employing release
pipelines.
Continuous Delivery
Automate publishing, and
in some case, deployment
to production, of builds.
Microservices
Change the architecture of
your application to
optimize/enable scale-up.
Infrastructure as Code
Codify your infrastructure
so it becomes part of your
automation.
Communication &
Collaboration
Enhance cooperation in
your organization across
different departments.
Monitoring
Collect live data from your
application while users run
their business on it.

13. Continuous Integration
Commit
A change (feature or bug
fix) is submitted to the
repository for merge
into the codebase.
Run tests
Tests are run against the
generated build. If one
or more tests fail, the
merge job is aborted.
Integrate
When all tests are green,
the change can actually
been integrated into the
main codebase.
Git is the most common tool for storing
and sharing code. CI tools are built on top
of version control systems in order to
automate the process of merging changes
in a safe and controlled way.
CI tools
A key of CI is
ensuring that small
changes are
committed in the
reporitory. This
makes easier to spot
bugs and fix them.
Commit
often
Use Git or other
source control
systems to keep
your codebase
shared across team
members. Every
change is tracked
and reversable.
Source
control
CI is the practice of automating building,
testing and integrating code into the
codebase.
What

14. Continuous Delivery
Commit
A change (feature or bug
fix) is submitted to the
repository for merge
into the codebase.
Run tests
Tests are run against the
generated build. If one
or more tests fail, the
merge job is aborted.
Integrate
When all tests are green,
the change can actually
been integrated into the
main codebase.
Build
The final bits to be
deployed are compiled
and executables are
generated.
Publish
The build is ready to be
installed. The bits are
published in a location
or depoyed in PPE.
Thanks to CD, it is possible to alwyays
have builds at one’s disposal. With
good tests in place, ideally, every
produced build is shippable.
Builds always
available
CD should be considered as an extension of CI.
The pipeline is expanded with a few more
steps at the end where the release process is
also automated after every commit.
What

15. Microservices
Client svc
Service responsible for
facing the user’s
requests and redirect
them to the back-end.
Business Logic
Services running the
different parts of the
application’s logic
Security svc
Service responsible for
taking care of
security-related
operations.
Data svc
Service responsible for
feeding data to
requestors and hosting
one or more databases.
Authentication
Service responsible for
taking care of
authentication-related
requests.
An architectural pattern that
applications should follow. The
different parts of the logic are
separated and hosted in
isolated processes residing in
different services.
What
One word: Scalability. By using
MS architectures, it is possible
to easily scale up or down an
entire application in the cloud.
Why
Diagram showing
the architecture of
a possible
application divided
into its main
components. Parts
communicate via
the HTTP protocol.
Example

16. Monitoring
Analyze
Developers analyze
results in next iteration
and take action accord-
ing to feedback.
Collect
All feedback from
application is collected
and assembled thanks
to predefined queries.
Log data
Your application and
your code has to be
instrumented to emit
usage informartion.
20%
35%
10%
7%7%
10
20
30 30 40
The ability to collect usage data from your
application and react on it as part of the ordinary
development process.
It is a way to get feedback from your users
without bothering them asking for it.
What
The Team must
ensure to have
telemetry
analysis and
action as part of
its development
process.
Process
feedback
Logging telemetry is
good, but you must
ensure you log
enough information
and, at the same
time, you don’t log
too much.
Careful
For many reasons. Catching issues before they
surface, improving the user experience,
improving the service and its components.
Why

17. The End
Thank you
This work is licensed under a
Creative Commons
Attribution-NonCommercial-NoDerivatives
4.0 International License
Cover: Super Agile City
This work includes artworks
designed by Freepik.com.
April 2018
v1.0
Keywords
#methodologies #devops
#agile #techtalk #microsoft #it
#technology #software
#engineering #development
Presentation info
Duration: 30 mins.
Background: Technical
Audience: Developers and
operations
This work includes artworks
designed by Shutterstock.com.
Andrea Tino
Software Development Engineer
Twitter:
E-Mail:
@_atino
andrea.tino@microsoft.com
Conference KMD Copenhagen May 2018, hosted by: