DevOps @ Enterprise - Lessons from the trenches

© 2014 IBM Corporation
Accelerating Product and Service Innovation
DevOps@Enterprise
Lessons from the trenches
Marcelo Sousa Ancelmo
Senior IT Specialist – IBM Rational
marcelo.ancelmo@br.ibm.com
https://twitter.com/marceloancelmo
https://www.linkedin.com/in/marceloancelmo
http://www.slideshare.net/marceloancelmo
marceloancelmo

What Is DevOps for you?
3

Sometimes people come with this
4

And this is what we often hear on enterprises
5
“DevOps? We already do that. Call the DevOps team here to talk with this
guy” - Business Savvy Executive, thinking that DevOps is just a new team
“We have a Continuous Integration environment here, we just need to
convince people to use it” - Early promoted IT Manager, coming from a
successful IT project
“We have a Release Process that is too much rigid, this will never work here”
- Developer or Operations guy (pick any), helpless about his future
Disclosure – ALL OPINIONS ARE THEIR OWN! (Phrases and people can
change at your own will)

What they need to realize is that a DevOps approach...
6
… Are a cultural change on how teams work and interact with each other, inside a
well structured process
… Requires a collection of techniques to maintan standards and lower the chances
of drifts
... Implements a lot of practices, to continuosly and consistenly apply the techniques
… Make usage of tools, to help people do their jobs better, apply the techniques
and practices and to monitor all the environment
All of this to deliver the consistency, collaboration, transparency and feedback
necessaries to the Enterprise

Executive leadership is vital
7
C-Level, VP, Higher Manager (Higher is better)
Have power to put everyone “on the same room”
Can help break the silos and bring people in
Make connections between silos and keep the path clear to move forward
Defend the DevOps initiave in front of others executives and on meetings
Advocates on culture change ...
… but all of this does not mean nothing if people do not ENGAGE

Culture change should be top level priority
8
This is especially difficult on the Enterprise, where a lot of people have different
responsabilities, departments are siloed and different practices are scattered
... and don't forget that there are political reasons too!
For succesful DevOps adoption at the enterprise you must engage everyone
involved – From Enterprise Architecture to Operations
They mut perceive the value that the enhanced collaboration, communication and
transparency of a DevOps Strategy can bring to them.
This is why the cultural barrier is one of the most difficult challenges and shoud be
the principal target for rolling out DevOps at the Enterprise.

Engaging strategies
9
Mix the teams, put someone from the Development on the Operations team for a limited
amount of time and vice versa, so they can “fell the pain” and know “Who is on the
other side of the phone”
Development and Operations should use the same tools to plan, track, build, deploy,
release and monitor. This will increase collaboration at the software development lifecycle
Share knowledge – Use Wiki, blogs and foruns to collaborate and spread information. Be
social and transparent
Create a DevOps commite with members from all of the enterprise. Everyone should
have an active voice.
Be aligned with strategic initiatives from the Enterprise, delivering real value all the time

DevOps @ Enterprise Use Case
10

What we found
11
The Good
A well established SCM + Issue Track + Continuous Integration environment
Teams that are using this environment and are getting great results
The Bad
Some teams did not get any perception of value by adopting this solution
Others teams did not have “time” to make necessary adjustments and migrations to use
this environment
Some teams did not even know that threre is such environment
The Ugly
No Executive Sponsorship
No clear communication and collaboration with testing and operations teams

First Bussines Challenge: Prove Yourself
12
Business Income: I did not believe you!
Challenge: To Prove DevOps value
Strategy: Find a project to be our pilot
What worked:
Found an Agile team that embraced the challenge;
We partened with them and created a “War Room”;
Deep understanding of the Enterprise culture and who are the key players;
After 3 months, they raised productivity more than 30%
What don't worked well:
Operations still did not fully engaged
No corporate standard for SCM and Versioning
Different deployment scripts for the environments
Business Outcome: Good Job, let's see what happens when we work at scale!

Second Bussines Challenge: Present your strategy
13
After the pilot result, a lot of teams started to ask how they could participate
Followed an Agile approach, with releases at each 6 months, aligned with enterprise strategic
objectives
Each release was broken into small deliverables (1 month each) that should:
Introduce some practice, technique and / or tool
Must be put on practice by at least one team
Should address a real business challenge
After the end of each delivarable, we make a retrospective of it
What worked
What did not worked
What could be improved
What must be changed

Dev + Ops – Working together for business benefit
14

Infrastructure Change Management
Tools chain:
Development – Eclipse
Plan, Track and SCM – Rational Team Concert
Software Definitive Library – Rational Asset Manager
15

Build Pipeline
Tools chain:
Development – Eclipse, Rational Application Developer or Rational Software Architect
Plan, Track and SCM – Rational Team Concert
Continuous Integration and Build Automation – Rational Build Forge
Software Construction – Apache Maven and Apache Ant
Software Quality Testing – SonarQube
Software Security Testing – IBM AppScan Source
16

“Continuous delivery is about putting the release schedule in the hands of the business, not in the hands of IT.”
- Jez Humble
Software Definitive Library
Runs immediately after the Continuous Integration QA phase
Publishes the resulting artifacts to SDL
Tools chain:
Build Automation – Rational Build Forge
17

Metamodel for Applications
18

Can be run at any time (including just after the delivery phase as part of the build pipeline) for a published
application.
Tools chain:
Deployment Automation – IBM UrbanCode Deploy
Deployment Pipeline
“The primary goal of continuous deployment is not to deploy continuously. It is to be able to deploy
continuously..” - Paul Klipp
19

Delivery Pipeline
Path followed by an application through its lifecycle
You can quickly ask to the Software Definitive Library which version is deployed where
Everyone involved and interested in the process are communicated
Tools chain:
Plan, Track and Collaborate – Rational Team Concert
Deployment Automation – IBM UrbanCode Deploy
Release Management – IBM UrbanCode Release
20

Lifecycle for the application
21

Benefits realized so far
Integration and traceability on the whole Software Development Lifecycle
Smooth transition and better communication between Development and Operations
Traceability between Build – Deploy – Defects – Testing – Code - Requirements
Rollout to new users facilitated through an standardized process
BOM of tools and scripts installed on all environments
Lower configuration drift
22
Following Releases:
Now - Release Management
Next - Continuous Testing

Closing the gap
23

They need to see it as a evolutionary process
24

That should be adopted in a Lean way
25

They need leadership and guidance...
26

...To do right things right
Image: www.nguyenduykhanh.info
27

Questions
Image: FreeDigitalPhotos.net

Thank You
Merci
Grazie
Gracias
Obrigado
Danke
English
Japanese
French
Russian
German
Italian
Spanish
Brazilian Portuguese
Arabic
Traditional Chinese
Simplified Chinese
Hindi
Tamil
Thai
Korean
Dziękuję
Polish
Marcelo Sousa Ancelmo
Senior IT Specialist – IBM Rational
marcelo.ancelmo@br.ibm.com

DevOps @ Enterprise - Lessons from the trenches

More Related Content

What's hot

Viewers also liked

Similar to DevOps @ Enterprise - Lessons from the trenches

Recently uploaded

DevOps @ Enterprise - Lessons from the trenches