Enterprise DevOps from the trenches

Jonny Wooldridge

Head of Web Engineering @ M&S&

Chief Geek @ enterpriseDevOps.com

15th May 2014

Intro

Aims of the next 30 minutes

Our definition of Enterprise DevOps

Why is Enterprise DevOps relevant to you?

10 Tips from 3+ years of getting DevOps working in an Enterprise

I’m not trying to sell you a ‘DevOps’ Tool.

I’m not trying to sell you my latest book.

I have a family and a day job, so forgive the odd spelling mistake!

Word of warning

These are my personal views, not the views of my employer. If you have a different view on anything in this presentation, I’d love to hear from you!

Me

2000-2003Web Master / Lead Java Developer

2003-2007Lead Developer / Head of Development

2008-2011Director of Platform Development

2011+Head of Web Engineering

Definition of Enterprise DevOps?

It is about better software delivery practices

It is end to end – from requirement to production

It is about best practice in connected tooling

It is about being fast and lean

It is understanding the operational requirements of a system and making it easier to support/deploy

It is understanding the trade offs. You can’t automate the entire Enterprise in one go.

It’s about evangelising the power of great software engineering practices.

Why (I hope) this is relevant to you?

Your start-up might be the next enterprise!

Enterprise experience is 100% relevant to a start-up

What can you do now to maintain DevOps momentum and not slow down as you grow?

Being good at software engineering cuts across all aspects of an organisation, of any size.

TIPS/LESSONS LEARNED

Define what you are trying to achieve and why?TIP#1

Define what you are trying to achieve and why.

Plan your attack: It may be boring but you need a plan and define clear goals explaining the benefits of a DevOps approach in the enterprise. What is your definition and how exactly will that be the game changer? Spell out the benefits but also create a sense of urgency as moving to a better software engineering approach in your enterprise is non-negotiable.

Keep it simple: There will be a lot of people who will not have even a basic understanding of the steps required to make great software. They may have had experience in the past of a bit of coding or might have some understanding of Ops but assume that they know nothing. Knowing a little bit from 10 years ago is actually worse than knowing nothing so be sure to explain how the industry has moved on.

Define what you are trying to achieve and why.

Show it working…: You can have all the powerpoint presentations in the world describing your approach and the benefits it will bring but in an enterprise people won’t get it until you actually show something actually working. Choose an application that they are familiar with.

… and supplement with diagrams and animations. People in the enterprise are less likely to get excited by the latest scripting platform, test automation tool or cloud service! That is until they realise what benefits it has for them or their team. Show it in pictures and compare and contrast old ways of working.

Make it clear that you care: In an enterprise you will find that if you clearly articulate that you care that software engineering is done well and can prove how ultimately it will make the organisation run better other teams will soon start to come to you for thought leadership

Define what you are trying to achieve and why.

Be an expert at the basics:

Greater productivity through reliability: DevOps is an investment in tools, processes and people throughout all phases of a project to provide repeatable, reliable, and secure environments. 

Standard Developer Machines

Continuous Integration

build systems

‘DoD’ * throughout

lifecycle

Standardised Binary

Deployment

Robust Source Code

Management

Reliable Environment propagation

SecurityStandards

Coding & Testing

Standards

* Definition of Done

Define what you are trying to achieve and why.

Define the pace of your appsTIP#2

Define the pace of your apps

Danger: Don’t assume they all go at the same speed!

Define you path to production which will help you….

Define what paces you have. As an example:

FAST - applications you can continuously deliver that are decoupled and have a great % of automated tests

MEDIUM – applications that are coupled and need end to end regression testing (hopefully mostly automated)

SLOW – Projects dependent on Corporate Release Cycle (SAP etc.)

Put in place different governance for different paces

Understand your pace dependencies

Define the pace of your apps

Ecommerce EngineBasket, offers, personallisation,

up-sell, payment

Digital AssetsImage and video storage

Content Mgmt.Page Content & Templates

Search SystemFacetted navigation, search

Apps Web

Staff AppsResponsiveAdaptiveRESS

IOSAndroid

ReportsFront End User Interface

API

Customer Mgmt.Customer contact, CRM

Communication Emails, text, chat

Connectivity Layer (enterprise service bus)Routing, security, transformation, connectivity

Order Management

Orders, refunds, cancelations, stock, fulfillment, POS

Product Information Product

Catalog and Attributes

Delivery SystemsCourier/Standard delivery/Labeling

Payment Systems

Finance Systems

Fast

Medium

Slow

Frequency of change:

A typical start-up route to production

Start-up*

★★★★

Stage 1 > Stage 2 > Stage 3 > Stage 4 >

Development Continuous Integration

Staging /Performance Production

Define the pace of your apps

Relatively Easy to continuously deliverInto this environment– buy the book!

* Assumes a startup-up with a non-complex architecture

Fast

Frequency of change:

Are you brave enough to do continuous deployments for a payment module that your whole £multi-billion business relies on?

Not all apps should be treated in the same way.

How well de-coupled are they? Automated tests?

Define the pace of your apps

Slow

Frequency of change:

Define the pace of your apps

Development Continuous Integration System Test Product

Group SITFully connected Corporate SIT

Staging/ Performance Production

Decoupled

Isolated

Project

Corporate

★★★★

★★★

★★

★Conti

nuou

sly

Del

iver

y Sl

ider Continuou

s

Continuous

Continuous

Continuous

Continuous

Continuous

Continuous

Continuous

Continuous

Continuous

N/A

N/AN/AN/A

N/AN/A

Standard Standard Standard

Standard Standard

Standard Standard

Continuous StandardKey:

An environment continuously deployed to

An environment where deploymentsAre managed in a standard way

Standard

Different Release types affect how fast your apps can go into production

Define the pace of your apps

The idea being that you should always aim to continuously deliver your apps into production

HOWEVER, if there are reasons why you can’t or don’t want to, make sure you can continuously deliver your apps into lower environments.

Factors influencing how far you go with Continuous Delivery:

how many environments you have

how well you have control over the deployments made into those environments

how many other teams are sharing the environment

Kill dependenciesTIP#3

Kill Dependencies

– Obsessively understand and control your dependencies– Decouple your apps & architecture – create services– Decouple your people – give them more responsibility E2E– Integrate with 3rd parties carefully– Stubbing is a solution– Less Dependencies = Easier Testing

Focus on MVPTIP#4

Focus on Minimal Viable Products

– What is the minimum you could go live with that will add value for your customer

– See if it works then improve it– A change to culture and requirements only but has a

massive impact on solution

DevOps is therefore End 2 End from requirement to production

Be aware that DevOps affects every aspect of your organisationTIP#5

DevOps affects every aspect of your organisation

– Technology and Architecture choice– HR, recruitment and rewards– Finance – funding allocation and Total cost of

ownership– Governance– Auditors – should love DevOps btw ;-)– Suppliers & Contracts – which projects to

offshore?– Ways of working – always can improve

DevOps affects every aspect of your organisation

Stage 1 > Stage 2 > Stage 3 > Stage 4 > Stage 5 > Stage 6 >

Development Continuous Integration System Test Product

Group SIT Corporate SIT Staging/ Performance Production

Decoupled

Isolated

Project

Corporate

★★★★

★★★

★★

★

CAB

CAB CAB

VSSame Day

EveryQuarter

Angular.js, bootstrap.js, mongodb, ScalaBDD and Continuous integration,

Struts, mainframe, test data issues, infrastructure SLAs

Affect on recruitmentDo more with Less

You are unique. Think for yourself.TIP#6

You are unique. Think for yourself

Take guidance from best practice, but don’t be afraid to innovate

What’s appropriate for you may not be appropriate for somebody else

Having a DevOps Team might be an ‘anti-pattern’ but it might work for you:

To build frameworks to empower agile teams to do their own devops

Provide shared tooling where it makes sense

Sort out contractual arrangements for the enterprise for cloud and tooling providers

Make your tools work for you.TIP#7

Make your tools work for you

Make your tools work for you, not the other way around

Embrace OpenSource it’s generally years ahead of the main vendor thinking

Don’t believe the hype

Why has the GUI seduced you?

Deployment for Dummies? If you can script it, why do you need an expensive tool?

TOOLS GAP: one area that is lacking in OpenSource is visibility of your working pipelines – how are the deployments progressing? What stage are they at? What’s the status?

Build a Software FactoryTIP#8

Build a software factory

Build a software factoryWhat is a factory? Let developers focus on the creative aspects of writing code, not how their code gets into environments for testing

Connect your tooling to get value

EXAMPLE: what’s in a build, differences between two versions

Don’t forget security! Add them into your build pipeline.

Maintain ownership of your delivery pipeline at all costsForce all suppliers through your pipe without exception

Get visibility of every code commit

Out source your dev, but keep them honest by making everybody come through your factory Machines.

Build a Software Factory

Don’t (just) focus on Deployment automationTIP#9

Don’t (just) focus on Deployment automation

Requirement to ProductionRisk of local optimisation

Make it as fast as possible but be realistic

Testing is the real problem – and how do you scale it

Requirements – INVEST sessions

Think like you’re the Enterprise of tomorrowTIP#10

Think like you’re the Enterprise of tomorrow

Make the right choices with:Technology

Hiring

Contracts

3rd Parties

Make the wrong choices and your DevOps dreams can be shattered

We need each other

Thanks for listening!