Continuous Deployment: What happens afterwards

Keynote

Jim Coplien, Gertrudandcope

Jim Coplien

Jim Coplien has over 40 years of experience in software development and has been a pioneer of object-oriented design, agile development process, and software patterns. He has written books covering a versatile spectrum of disciplines ranging from organizational structure to programming. Cope leads and facilitates the industry Scrum PLoP® community effort (scrumplop.org) to create a de facto standard of rationalized Scrum.

Jim gives a refreshingly different view on continuous-x in his keynote. This is the abstract in his own words:

Continuous deployment helps the enterprise finish its work and ready the product for delivery into the client’s hands at a moment’s notice. Technology can triumph over uncertainty. But the bigger challenges lie in managing the market expectations, and those of the people outside the enterprise — the end users. It’s less about being always ready to synchronise with your readiness rather than theirs. Software is never just a product, and delivers value only when running and providing a service. So it’s not really about either the product nor about delivery. It must be a living product. This means that the product isn’t at the end of the deployment loop but that it is in the loop. Continuous service doesn’t end with delivery, but starts there.

Twitter: @jcoplien Publications: gertrudandcope.com

Great Artists Steal: Adding Git Support to Microsoft Visual Studio

Edward Thomson, Microsoft

Edward Thomson Edward Thomson is a Senior Software Development Engineer at Microsoft, where he develops Git integration for Visual Studio and Team Foundation Server. Edward is a core contributor to the libgit2 and LibGit2Sharp projects, which are the open-source Git libraries used by Microsoft tools (and many others). Edward is a contributing author to “Professional Team Foundation Server 2013,” available from Wrox Publishing.

His speak at CoDe CPH has the title Great Artists Steal it refers to the decision Microsoft made regarding the underlying versions control system of TFS, simply to cease development on their own technology and just give the users what the wanted: Git. The abstract in Ed’s own words goes like this:

In 2011, Microsoft was building “Team Foundation Version Control”, a centralized version control system for enterprises. Two years later, we were building Git support into Visual Studio and Team Foundation Server. Learn how Microsoft avoided “not invented here” syndrome and adopted a great tool for its Distributed Version Control System by using Git (instead of creating an inferior copy of Git) and learn about the mistakes we made (and the ones we avoided) along the way.

Twitter: @ethomson Blog: edwardthomson.com

The Rationale for Continuous Delivery

Dave Farley, Continuous Delivery Ltd

Dave Farley Dave Farley is a thought-leader in the field of Continuous Delivery, DevOps and Software Development in general. He is also the co-author of the Jolt-award winning book ‘Continuous Delivery’ a regular conference speaker and blogger and one of the authors of the ‘Reactive Manifesto’.

Dave has been having fun with computers for over 30 years. Covering most types of software, from firmware, through tinkering with operating systems and device drivers, to writing games, and commercial applications of all shapes and sizes.

Dave has a wide range of experience leading the development of complex software in teams, both large and small, in the UK and USA. He was an early adopter of agile development techniques, employing iterative development, continuous integration and significant levels of automated testing on commercial projects from the early 1990s.

Today Dave is an independent software developer and consultant, and founder and director of Continuous Delivery Ltd.

Dave presents his speak at the CoDeCPH conference like this:

Many people working in software development spend their careers without seeing what good looks like. Our history is littered with inefficient processes creating poor quality output, too late to capitalise on the expected business value. How have we got to this state? How do we get past it? What does good really look like? Continuous Delivery changes the economics of software development, find out how and why.

Twitter: @davefarley77 Blog: www.davefarley.net

Continuous Delivery War stories - deploying 10 times per day

Allan Ebdrup, E-conomics

Allan Ebdrup Allan Ebdrup studied Computer Science at universities in Århus and København. He has worked 16 years in IT as self-employed, developer, IT-architect, enterprise-architect, tech & team-lead. Three years ago Allan took the leap form working with technologies from the evil empires of Microsoft, Oracle and IBM to working exclusively with Open Source technologies like Node.js, NoSql and MongoDB. The talk is about:

How to do Continuous Delivery and deploy to production 10 times a day or more. The techniques in the talk can be used no matter if you are on an Open Source technology stack or not.

Twitter: @allanebdrup Blog: version2.dk

What does Continuous Delivery demand of me as a person?

Mark Coleman, Implicit-Explicit

Mark Coleman Mark Coleman is the founder of implicit-explicit.com, a founding member of Docker Amsterdam, an associate at Container Solutions, and a co-organiser of DockerCon Europe 2014. He has more than 10 years of experience in Software Development, Configuration Management and IT Operations and has helped some of Europe’s largest companies to change the way they create, deliver and market software to their users. When he’s not hacking tech, he’s hacking humans. Why do they do the things they do? Mark lives in Amsterdam, the Netherlands.

In this talk we will assume that continuous delivery is the solution to your problem and will discover through various stories which character traits should be present in your team members if they are to build and deliver cutting edge software. We will conclude with suggestions on how to build such a team.This is a non-technical talk for anyone who is managing, or is a member of, a team who are trying to implement continuous delivery.

Anyone looking to learn more about Continuous Delivery can find reams of information; from tooling to organisational design, it seems that all topics are covered by an ever growing amount of information in books and online. Over the last 5 years I’ve introduced continuous delivery to several teams, and in every single project, the biggest hurdle to be overcome is not one of insufficient knowledge, but one of personality. Quite simply, if your team were already mature enough to implement continuous delivery, and if continuous delivery were the solution to a problem they were facing, they would have already implemented it. If you’re struggling to implement continuous delivery then, that can only tell you one of two things:
1. Your team is not mature enough.
2. Continuous Delivery is not the solution to your problem.

Twitter: @mrmrcoleman

NoOps - beyond the DevOps frontier!

Lars Kruse, Praqma

Lars Kruse Lars Kruse, Continuous Delivery Coach and partner and co-founder of Praqma. Lars holds a M.Sc in computer science and communication theory and has many years of experience in software configuration management, processes automation, quality assurance and agile software development.

In his speak Lars takes DevOps one step beyond forming a happy collaborative relation between Dev and Ops. He advocates for an entirely elastic and automated R&D infrastructure, with the software developer in the driver’s seat. In his own words:

A glimpse into a very near future where quality is actually built into the software, as opposed to glued on after it’s finished. It’s a future where software developers aren’t dependent on IT Operations at all. In a Continuous Delivery NoOps world queues have disappeared, resources are available at your command and everything is automated.

Twitter: @lakruzz Blog: lakruzz.com