Today,
Delivery of Things World 2016 - a conference about DevOps and continuous development - started in Berlin. It spans two days, and about 300 people participate. I attended the following sessions on the first day:
- DevOps and Moving the Elephant by Chris Gargiulo, Head of DevOps & Enterprise Service Platforms at Maersk Group (keynote):
- You have to start communication and work against fears.
- Continuous integration and continuous delivery are starting points for the journey towards trust in DevOps. He showed numbers of an example concerning decreased build times due to automation.
- First rule of DevOps: There's no crying in DevOps! I.e. you have to stand throwbacks and resist switching back to the old manual processes, learn from failures and watch out for potential improvements.
- Define a mission goal, adopt changes incrementally, quantify the results and celebrate success accordingly.
- Leading organisations that don‘t need leading by Mark Rees, former COO at E-POST Development (keynote):
- Their development units consist of several DevOps teams, each DevOps team in turn consists of a number of developers, a QA engineer and a delivery lead - kind of a mixture of a scrum master and a product manager.
- Responsibility and leadership always came up in discussions.
- Leaders should act as enablers and provide an environment for teams to become confident about taking responsibility for yet unexplored fields.
- Leaders should coach their teams in the beginning and then step back, delegate and provide support.
- Don't manage your teams, lead them!
- SecDevOps: How can we create cultural change to bridge this gap between security and DevOps? by Ben Hughes, Network Security Manager at Etsy:
- A typical DevOps pyramid: 10 developers, 1 ops person.
- Typical SecDevOps pyramid: 100 developers, 10 ops persons, 1 security person.
- Establish security champions: Join security conferences, hang around in relevant chats etc.
- Etsy does security bootcamps: Join a couple of other different teams for some time, then return to your home team (you are now well connected and got the security word spread).
- Security team culture:
- "Don't hire a**holes."
- Be approachable.
- Be transparent.
- Be humble.
- Act blamelessly.
- Create a culture where people report strange things happening rather than pretending everything is fine.
- "If you make security hard, people won't use it."
- Get everybody in your company/department to be "part of" your security team. Security is not something someone else cares about.
- Buy vs Build by Nishan Subedi, Senior Engineer at Etsy:
- A nice tour through the tools they built:
- Virtual Madness (set up and manage development VMs).
- deployinator (deploy code changes).
- supergrep (tail production server logs).
- StatsD (metrics collector).
- morgue (for blameless postmortems).
- The main ideas behind these tools:
- Encapsulate ideas.
- Provide reasonable defaults.
- Make users feel comfortable due to transparency.
- Technology is a product of the culture that builds it. The Etsy culture consists of:
- Just Ship! (I.e. enable frequent deployments of small changes leading to continuous deployment.)
- If it moves graph it!
- Optimize for developer happiness.
- Don't be an a**hole.
- Engineering with a capital "E" - "E" as in empathy.
- A new hire always does a "First Day Deploy":
- Learn from what you see (and do).
- Make implicit explicit. No knowledge hidden in a small number of brains.
- Etsy strongly considers itself a learning organization.
- Generali‘s journey to reduce release and maintenance downtimes by 90% by Torsten Rehfisch, Scrum Product Owner at Generali:
- They decided to use XL Deploy for deploying web applications into a IBM WebSphere landscape including every dependent artifact and configuration which is needed to run a web service.
- After a description of their evaluation process these results were shown:
- Deployment landscape: 6 XL Deploy instances (3x for development/integration, 3x for UAT/pre-production/production).
- Each XL Deploy instance is set up via Puppet.
- Jenkins is used for build.
- They gained speed, confidence, transparency and repeatability.
- From Need to Speed - How to successfully setup a DevOps transformation by Robert Michel, IBM Cloud Solutions Technical Sales at IBM:
- Levels of DevOps adoption to increase delivery speed:
- Agile development/continuous integration.
- Continuous delivery.
- Continuous deployment.
- Continuous operations.
- Start fresh with a new project, start small, and think of "developer first" and "cloud first".
- Evolving to Continuous Development: a skill set example by Sebastian Ehrich, Software QA Engineer at ebay Kleinanzeigen and Manuel Aldana, Senior Development Manager at ebay Kleinanzeigen:
- Iterating often leads to a smaller change set per single deployment/iteration, which leads to less risk, better traceability and faster feedback.
- Key success factors:
- Culture.
- Mindset.
- Communication & collaboration (e.g. create communication/collaboration spaces in order not to broadly disturb people, implement open meetings where people can decide on their own whether the meeting is of interest for them).
- Visibility and spreading the knowledge (e.g. metrics on wall screens).
- Automation.
- They are mainly looking for people fulfilling the t-shape model.
- Product teams are self-containing, i.e. each product team consists of a mix of required people like developers, QA people, designers, operations people etc.
- Use kanban (due to its inherent continuous improvement).
- DevOps for leaders by Adam Lukas Urban, Head of Order Management Development at 1&1 and Tim Schuppener, Head of Development Webhosting Infrastructure & Content at 1&1:
- Invention and adoption cycles get shorter and shorter (examples: steam machine, computer, mobile phone).
- Faster shipment is required.
- Collaboration (communication, transparency) and common responsibility are essential.
- CAMS.
- First day deployment (like they do at Etsy).
- Pair operations (like pair programming).
- Hackathons, team events, socializing/communications areas.
- For leaders/management:
- Define values & targets.
- Give time & space.
- Performance will go down. Don't start measuring too early.
- Retrospectives are the key to continuous improvement.
- Software is eating the world by Henk Kolk, Chief Architect at ING (keynote):
- The bank is IT, and the IT is the bank.
- ING's journey from an organization heavily driven by processes (e.g. there were times when 64(!) documents had to be written before getting the clearance to start coding) to an agile one.
- Their reorganization lead to 180 full DevOps teams (i.e. operations people and developers in one team).
- Later they integrated the business people, too, to build product teams being completely responsible for a product. With that they got rid of 2 management levels.
- Results of their journey:
- IT drives the commercial strategy.
- IT is a value driver.
- Hiring the best talents.
- Building as the way to understanding.
- Line drives the changes.
- Products and services.
- People.
- The Rationale for Continuous Delivery by Dave Farley, Author of Continuous Delivery (keynote):
- The scientific method:
- Characterization.
- Hypothesis.
- Deduction.
- Experiment.
- Repeat!
- Iterative development processes are more successful than traditional ones like waterfall.
- Lean thinking:
- Deliver fast.
- Build quality in.
- Optimize the whole.
- Eliminate waste (unnecessary variations, overburden, wasteful activities).
- Amplify learning.
- Decide late.
- Empower the team.
- Continuous delivery leads to shorter cycle times and thus enables iterative processes.
- Continuous delivery motivation:
- First principle of the agile manifesto.
- Logical extension of CI.
- Holistic approach to development.
- Every commit creates a release candidate.
- "Finished" means released into production.
- Continuous delivery gains:
- Repeatable and reliable process.
- Automation.
- Everything under version control.
- If it hurts, do it more often.
- Build quality in.
- Done means released.
- Everybody is responsible for the release process.
- Continuous improvement.
- The Google build process shows that CD scales:
- A single monolithic repository.
- All tests run on every commit.
- More than 100 million tests are run per day.
- Amazon does one deployment every 11.6 seconds, each deployment hits 10,000 servers.
- The DevOps transformation at the HP LaserJet firmware team e.g. resulted in 8x the capacity for innovation.
