[2016.11 Meetup #7] [TALK #1] Hugo Amorim - The delivery pipeline @ BPI

Imagine that you have an ecosystem with dozens of different technologies and IT systems that span from the decades-old to the cutting edge. How would you handle the integration challenges of an IT ecosystem with thousands of services and where a significant percentage of business requests cross-cut multiple systems? How would you shepherd all these changes from development to production, in compliance with regulatory demands, including strict traceability and auditability requirements? Oh, and with the robustness expected from a bank? Well, with some DevOps practices, that’s how!

Transcript

1. THE DELIVERY PIPELINE @ BPI How we’ve been doing DevOps…
2. who we are
3. WHERE DO WE OPERATE? THE CONTEXT
4. demanding environment
5. complex environment +60 dev teams +500 applicaIon components thousands of services
6. mulIple plaLorms
7. a lot of technologies!
8. always evolving… •  (very) frequent Change •  rapidly changing Market •  constantly adap@ng Business •  heavy Regula@on •  strict Audi@ng
9. HOW TO MANAGE AND SUPPORT THIS EVER-CHANGING “IT COMPLEXITY”? THE PROBLEM
11. the problem •  mul@ple SCM tools •  mul@ple Delivery processes •  some changes not managed by SCM tools •  lots of manual-based tasks •  challenging end-to-end traceability •  limited feedback
12. MANAGE, AUTOMATE, MONITOR THE SOLUTION
13. the pipeline RTC checkin z/os developer java developer iOS/Android developer
14. single SCM plaLorm •  Process “standardiza@on”
15. single SCM plaLorm •  Process “standardiza@on” •  Delivery Workflow •  Improved Traceability •  Accessible logs
16. manage everything •  Extended support for other types of Change: – Build configura@ons
18. manage everything •  Extended support for other types of Change: – Build configura@ons – Deploy configura@ons
20. manage everything •  Extended support for other types of Change: – Build configura@ons – Deploy configura@ons – Applica@on/Infrastructure configura@ons
22. manage everything •  Extended support for other types of Change: – Build configura@ons – Deploy configura@ons – Applica@on/Infrastructure configura@ons – Database
24. the pipeline RTC CI Hudson build deliver checkin
25. conInuous integraIon •  Builds started by RTC •  No manual interven@on on Hudson •  Build broken = Stop! •  Each environment has its own CI
26. conInuous integraIon •  Conven@on over configura@on •  Sta@c code analysis •  Security analysis •  Automated unit tests
27. the pipeline RTC CI Hudson Deployment Butler Ar@facts build deploy deliver checkin deploy install configure
28. automate •  One click deployments •  Reduce manual tasks •  Support different technologies •  Deploy database changes •  Deploy infrastructure configura@ons
29. ARE WE THERE YET? MAJOR BENEFITS
30. database deployments before •  manual tasks •  copy & paste problems •  encoding problems •  changes not applied •  out of sequence a[er •  no surprises •  always deployed •  zero wait for manual deploy –  from several days to just a few seconds •  database drop and recreate every week – the GEOS case •  the AIX case – from reluctance to enthusiasm
31. one click deployments before •  reluctance to deploy changes •  hard to know what is currently deployed •  deploy to black box •  limited feedback •  @me-consuming a[er •  consistent deploys on all environments •  the eCode pla`orm –  dependency nightmare solved –  infrastructure catalogued –  full pla`orm deploy in less than an hour •  real-@me feedback
32. feedback and self-support before •  most teams depended on our availability •  logs oaen inaccessible •  long development cycles •  reopening a change requested manual ALM interven@on a[er •  immediate feedback from delivery ac@ons •  logs available on RTC •  faster feedback = quick reac@on from development •  more autonomy
33. A WALK IN THE PARK NEXT STEPS
34. next steps •  Eliminate ALL manual tasks •  Extend types of changes •  (More) Automated Tests – Smoke tests – Func@onal tests •  Applica@on Catalogue •  Con@nuous Delivery