Here's the slides Jon Fletcher and I presented at Ranger 4's recent DevOps day, about the journey Hiscox haven taken while adopting some of the core principles of DevOps
reviews More deployment freezes More standards control boards More frequent changes Lower tolerance for outage More complex applications More complex deployments Do more! Do less! RFC’s CAB Deployment guide Rollback guide Daily status calls Staff availability Issue tracking Environment booking Escalation processes Emergency processes Small change processes etc etc Mr. Dev Mr. Ops
of working well together and aligning goals is limited to Developers and Operations? • Shouldn’t everyone involved in the change process work together to accomplish shared goals? • DevTestBizThingyOps should be the real name
London Markets UK UK Hiscox yesterday (ish!) IT capability IT capability Group development Group support Group infrastructure Group testing Group DBA Group release and deployment Group architecture
DBA Release and deployment Architecture UK UK Dev Support Testing DBA Release and deployment Architecture London market London market Dev Support Testing DBA Release and deployment Architecture USA USA Dev Support Testing DBA Release and deployment Architecture Bermuda Bermuda Dev Support Testing DBA Release and deployment Architecture
• Cradle to grave responsibilities • Shared goals and incentives • Underpinned by the Platform Services Group • What started out as an ambition to increase the pace of change has evolved into “rebooting” the IT team
challenging IT to find new and better ways to do things – Means working smarter not harder. Doesn’t mean an ever increasing head count • Platform Services helps break down silo’s between teams by providing a change platform that is re-usable between multiple teams • Help others use the platform (they don’t implement themselves!)
Speed, quality, cost - think like a start-up 2. One team with a common objective – single business & IT programme 3. Keep it simple - rewarding simplification above perfection
1. Check in changes Build (Maven) 3. Build Artefact repository (Artefactory) 4. Store artefacts Regression test (Selenium) 8. Test Performance test (JMeter) 9. Load test SysTest UAT Production 10. Deploy CI Test servers 7. Deploy CI (Jenkins) 2. Monitor for changes Continuously automated On demand – click button to deploy Deployment (uDeploy) 5. Instruct deployment Server config (Puppet)
Cost / release Manual Release 8 3 hours £1,650 Automated Release 2 20 minutes £45 Reduction 89% 97% 19 In the go-live week we did 47 releases, not only did we save £75k on release costs, but there’s no way we could physically done that many releases without significantly increasing team size.
think DevOps is just about the automation • There’s a massive cultural shift • If every change is automated, you know exactly what was changed, by whom and when. • We’ve taken away RDP access (there was lots of noise) • Audit is simpler • Training the team is much easier • Therefore its much easier to skill up
Deploy as our application deployment engine • Help deliver the 1st phase of the biggest change program Hiscox has ever undertaken – Risky? Couldn’t deliver it any other way! • 50 releases last week in 1 application alone • 17.5 man days of effort reduced to about 10 minutes • Help enable reducing a 10 week change cycle down to 2 weeks • We went from 1 person knowing how to do to do a release to thousands (kind of!) • Investigating proof of concept with IBM Rational Test Virtualisation Server
ROI calculations - management take these with a pinch of salt • Instead focus on time to market, avoided effort etc • How are you going to do it otherwise?
configure, test & support Deploy 2 weeks Review Business concepts for change Continuous analysis and prioritisation Create teams of “purple people”. They are not “blue” of the business or “red” of the technology, but a blend of the two, hence purple. This is the PITstop concept, this required a significant cultural shift both within IT and with our business teams. The team, use processes built on the principles of Agile software development The team use a number of automation tools, to speed up the delivery process, across build, test and deployment
change across people, process and technology, if you can’t change all three, you will significantly limit your success • It’s hard • It’s well worth it (measure everything to prove your success) • If you don’t do it, your competitors will
theboyg
akidon0000
ewolff
sansan33
hiramax
tomohisa
chack411
shinichitakeuchi
shift_evolve
kazzpapa3
masakiokuda
kaminashi
codingconduct
danielanewman
nmsamuel
philnash
chriscoyier
michielstock
cargoodrich
katarinadahlin
sarafernandez
rasagy
akihiro_kokubo
takai
