2016-04-25

Delivery of Things World 2016 - Day 1

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.

No comments:

Post a Comment