enterprise devops presentation @ magentys seminar london may 15 2014
Post on 22-Jan-2015
184 Views
Preview:
DESCRIPTION
TRANSCRIPT
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!
top related