Cutting Edge on Development Methodologies in IT

The state of the art of development
methodologies in the IT Industry
Cutting Edge
Andrea Tino (Software Development Engineer)

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?

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?

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

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 processes: ASD,
Dev
model
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
over Processes and
tools
Individuals and
Interactions
over comprehensive
documentation
Working Software
over contract negotiation
Customer Collaboration
over following a plan
Responding to Change

The 12 Principles of the Agile Methodology
Our highest priority is to
satisfy the customer
through early and
continuous delivery of
valuable software.
1 Welcome changing
requirements, even late in
development. Agile
processes harness change
for the customer's
competitive advantage.
2 Deliver working software
frequently, from a couple
of weeks to a couple of
months, with a preference
to the shorter timescale.
3 Business people and
developers must work
together daily throughout
the project.
4
Build projects around
motivated individuals.
Give them the
environment and support
they need, and trust them
to get the job done.
5 The most efficient and
effective method of
conveying information to
and within a development
team is face-to-face
conversation.
6 Working software is the
primary measure of
progress.
7 Agile processes promote
sustainable development.
The sponsors, developers,
and users should be able
to maintain a constant
pace indefinitely.
8
Continuous attention to
technical excellence and
good design enhances
agility.
9 Simplicity --the art of
maximizing the amount of
work not done-- is
essential.
10
The best architectures,
requirements, and
designs emerge from
self-organizing teams.
11 At regular intervals, the
team reflects on how to
become more effective,
then tunes and adjusts its
behavior accordingly.
12

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.

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

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.

DevOps
Deﬁnition
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
Beneﬁts
In order to successfully
implement DevOps, 6
practices can be
implemented.
6
Practices

Beneﬁts 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

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 deﬁnes 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

Practices in DevOps
CI CD MS
MC2IaC
Implement these practices ﬁrst
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.

Deﬁnition
noun
The process of automating the build and testing of code every
time a team member commits changes to version control.
Sam Guckenheimer
(Microsoft Visual Studio Cloud Services)
CI encourages developers to share their code
and unit tests by merging their changes into
a shared version control repository after
every small task completion.
Key
beneﬁts

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

Source Control
CI is based on following Agile
methodologies. Whatever your Agile flavor
is (XP, Scrum, Crystal, etc.), keep it and try
to improve it.
Work
Agile
Use a Source Control (like Git) to share the
code across the departments of your
organization. This will enable you to gain 2
very important achievements:
Share
code
Collaboration: developers can easily
work together while still in isolation.
Branching: Thanks to branches, you
can handle releases very well.

Commit often
Do not pile up stuff and commit large amount of code
changes. Instead, commit small changes.
What
It’s not because we like the feeling of committing stuff...
(well certainly some of us do). It’s more for the
following points:
Why
Risk of regressions: The smaller a change is, the
lower the risk to introduce regressions in the
codebase.
Bug fixing: If a commit introduces a regression, it
is easier to identify that commit. Also, the
regression can be caught up earlier and
addressed faster.

CI architecture
CONTINUOUS INTEGRATION
SOURCE CONTROL
Commit
into the codebase.
Test
Build
CI is built on top of Source Control systems.
Typically, systems like Git will allow
developers to hook up to certain events, like
commits.
By using the Source Control’s API, it is
possible to react to these events and trigger
the build and publish process.
Stacked
CI systems are built to create a chain of
operations which typically involve the most
common steps: code is committed, then
tested and, if tests are green, finally built.
Build
chain
All generated builds are typically saved in a
secure location so they can later be picked
up for deployment. Typically, a cloud
storage is used.
Build
bucket

Don’t re-invent the wheel
Today there are many companies
which have created cloud solutions
for offering integrated CI tools.
They all can interface with the
Many
options
most common source controls (like
Git) and do provide, out of the box,
many tools for collaboration.
So no need to implement CI on
your own, even if your
requirements are very special,
think twice before playing solo :)
By using one of the
many CIs available on
the Internet today, an
organization can
avoid spending so
many resources
building and
maintaining such an
infrastructure. All of
these services have
pros and cons, so pick
the best one for your
needs and scale and
have fun by
automating your
build system.
If your application has
special requirements,
be aware that almost
all of the solutions
available today
provide high levels of
customization via rich
API you can use.

Continuous Delivery & Deployment
Commit
into the codebase.
Run tests
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

Continuous Delivery
Deﬁnition
noun
The process to build, test and release from a build to a
pre-production environment.
Sam Guckenheimer
Without Continuous Delivery, software release cycles
were previously a bottleneck for application and
operation teams. Manual processes led to unreliable
releases that produced delays and errors.
Improved
process

CD architecture
SOURCE CONTROL
CONTINUOUS DELIVERY
CD is built on top of CI. As soon as CI is
over, a new build is available. The build is
published.
Nothing happens to Production
environments, if the build is picked-up for
release, the process of approving it is fully
manual.
On top
Commit
into the codebase.
Test
Build
Stage to PPE
Build is deployed into a
pre-production environ-
ment and published for
download.
In order to test the
product E2E, it is useful to
automate the deployment
into a non-production
environment acting as a
safe playground.
Pre
production

PS1T2
Build
A new change is pushed
into the pipeline and the
updated version is built.
Stage to PPE
The build is staged to
PPE into another
separate environment
for E2E testing.
Swap slots
Traffic is redirected to
the new slot leaving the
previous one idle.
Stage to slot
A slot is created to
validate the environ-
ment and run a
warm-up test.
PT1
Build
The first iteration gets
built and executables
are available after
running tests.
Stage to PPE
Bits are deployed into a
test environment for E2E
testing.
Stage to PROD
After validating the
build, bits are deployed
into a newly created slot
in production.
Approval definition
Pipelines can include
deployment stages. Those
can be guarded by manual
approval locks which pause
the pipeline.
Release pipeline
AWS gives developers the
ability to define a task
pipeline with customizable
stages to cover the different
steps for building software.
Slot swapping
Thanks to slots, it is possible
to test a slot before turning it
into production by just
redirecting the production
traffic.
Deployment slots
Microsoft Azure has
introduced staging slots in
order to facilitate the
delivery of new versions of
your application.

Continuous Deployment
Deﬁnition
noun
The process to build, test, configure and deploy from a build to a
production environment.
Sam Guckenheimer
Though similar, very similar, the definitions of
Continuous Delivery and Continuous Deployment
do actually differs from the very last step. They are
two different practices!
Attention

CDp architecture
SOURCE CONTROL
CONTINUOUS DELIVERY
CONTINUOUS DEPLOYMENT
CDp is the last step in the release pipeline.
If present, it is built on top of CD.
The foundamental point is that the
process is fully automated. As soon as the
build is emitted and passes all tests,
customers will have immediate access to
it in their Production environments.
Final
stage
Commit
into the codebase.
Test
Build
Stage to PPE
download.
Stage to PROD
Build is deployed
directly to production
into the customer’s live
environment.

Warning
Continuous Delivery
Always remember that
the following holds:

Commit
into the codebase.
Test
Build
Stage to PPE
download.
Stage to PROD
Build is deployed
environment.
Cont. Integration Cont.
Delivery
Deployment
Continuous Delivery
The deployment must wait a
manual approval process to
grant permission.
As soon as the build is
available, the release
definition deploys it to
Production.
Automatically
triggered as
build is over.The way the
deployment is
triggered is the key
point which
differentiates the two
practices.
In CD, deployment to
DevOps
Continuum
production is done
manually over
permission granting.
In CDp this happens
automatically and the
buid goes straight
into Production!

Fast deployment rollback
Everything can go wrong, if it does, a
process for rolling back a deployment to
the last stable build must be in place.
E2E automation
Having E2E tests is important so that
high critical user scenarios are tested.
Code coverage
Good testing is a must. Ensuring all code
paths are also covered is important to
have a good guarantee the product is
high-severity bug-free.
Continuous Deployment is a risky practice
because builds get deployed straight into
production.
An organization must be prepared to
make this step, and some key
requirements can help you understand
whether you are ready to implement CDp:
Be aware

It takes time
Cont. Delivery
Builds are published
and automatically
deployed to PPE.
Cont. Deployment
Customers receive new
deployments
automatically after
every commit.
Cont. Integration
Builds automatically
generated after every
commit.
Agile development
Engineering Teams
work with Agile
methodologies.
Think about it, CDp is cool
but is also pretty scary!
Deploying automatically to
the customer means that
every uncaught bug is
going straight to
production!
Given this high risk, CDp is
a practice that not many
can achieve and should
implement.
The point is, if you wanna
get there, be aware that
this last step in the
continuum takes long time
and much effort.
You
gotta
be
ready

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
taking care of
security-related
operations.
Data svc
feeding data to
requestors and hosting
one or more databases.
Authentication
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

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

Application Telemetry
Service Monitoring
There are different ways to ask for
feedback from your customers. One is
asking them, but we know it can be
bothersome for users to answer online
questions.
So we have instead our application tell
us about the user experience and how
the application is performing.
Data from
your
application
Today’s cloud systems allow
organizations to deploy solutions fast.
They also provide monitoring tools
out of the box with nice and cool
dashboards to check the state of your
services and notifications to get
alerted when something’s wrong.
Service
health
check

Why should I be so
concerned about
Telemetry?
Q
“You don’t go to the
Cloud without some
good Telemetry. It would
basically be suicide!”
A
A manager I heard in oﬃce the year we were
launching our solution to the Cloud

Commit
into the codebase.
Emit telemetry
The product emits telemetry
as users work on it. Services
are responsible for storing
telemetry data in the cloud.
Collect telemetry
Periodically, as part of the development
process, Teams collect telemetry and
process the results by aggregating data
and producing actionable output.
Act on telemetry
Basing on results from telemetry,
the next iteration of the product
will contain bug fixes or features
which improve the product.
Test
Build
Stage to PPE
download.
Stage to PROD
Build is deployed
environment.
Customer provides its feedback in a passive way! Thanks
to telemetry, it is possible to log user’s activity.
Feedback
The product undergoes development, testing and
deployment. In this phase, the direction is from Teams
to the customer.
Development

The End
Thank you
This work is licensed under a
Creative Commons
Attribution-NonCommercial-NoDerivatives
4.0 International License
Cover: Wave edges of IT
This work includes artworks
designed by Freepik.com.
October 2018
v1.4
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 II
Twitter:
E-Mail:
@_atino
andrea.tino@microsoft.com
Seminar on Development Methodologies October 2018, hosted by:

Cutting Edge on Development Methodologies in IT

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Cutting Edge on Development Methodologies in IT

Semelhante a Cutting Edge on Development Methodologies in IT (20)

Mais de Andrea Tino

Mais de Andrea Tino (20)

Último

Último (20)

Cutting Edge on Development Methodologies in IT