DevOps

What works for me might not work for you. Reverse. Repeat.

Earlier this week I posted my thoughts about DevOps and Continuous Delivery. TheSunshine tester responded on Twitter with a strong defense for Agile

I love that methodologies are able to create such passionate responses. Even amongst the truly committed I doubt I would find any passion for the Waterfall method. Yet the Agile, DevOps, and CD communities seem genuinely excited about working together in this way.

Software Development has greatly improved in the last few years but I still think we have a long way to go before it is considered reliable. Last year CIO.com reported that the majority of ERP projects are over time and over budget. If Agile is truly the silver bullet then all teams would be adopting it, and finding success with it. Unfortunately that doesn’t appear to be the case.

No matter how successful Agile, or any practice might prove to be we should still be seeking new and better ways of working. Humans are unique and our involement makes every project equally unique. The team who has success with agile is unlikely to have the same team make-up, or collective experience as one who doesn’t transition, or who fails to succeed with agile. Our interpretation of what a process involves, and our previous experiences all serve to influence what the end process will actually look like.

We need to have discussions about DevOps because it has arisen from an apparent divide between developers and Ops people. Whether this divide is caused by agile, or a failing of the implementation is irrelevant, the fact is that many teams are finding things as they stand are not good enough.

At Songkick we’ve followed Lean practices for many years. We have small cross-functional teams, daily stand-up meetings and weekly retrospectives. We measure things and try to remain flexible and responsive. Despite this we were having trouble releasing working software. Implementing Continuous Deployment was an enhancement to our agile practices. It went beyond giving us a framework for working together and gave us the steps we needed to make frequent releases too.

One of the criticisms I often hear is ‘it wouldn’t work here’. Hopefully these reservations come from understanding that there are no best practices, but whatever your reason for resisting copy-book change you are right.

What has worked for me, in my team, on my project will never work in exactly this way with your team.

Simply put, best practices do not exist.

Continuous Delivery is the current trendy approach and that is a concern. You should be trying to fix a problem not copy a textbook. If you cannot identify the benefit of any practice, agile ones included, then you shouldn’t be using it. One of the most valuable skills we learned from adopting Continuous Delivery was the ability to review our process and identify exactly what was working and what wasn’t. We continue to review things, making changes as our needs, or the team, changes.

Talk to other teams, listen to their experiences, read widely but use their processes as your guide. The most useful thing you can learn from other teams is how they implemented change. What were the triggers or warning signs? How did they know it was working? How did they choose this change?

These are things that you can apply to your own situation. These are the things that are likely to actually help you deliver good software.

Advertisements

DevOps with Testers

Last week I spoke at QCon London about Songkick’s experience of moving to Continuous Delivery. You can download the slides, or watch the longer version of this talk on the LondonCD Meetup’s Vimeo channel.

My talk was part of the DevOps and Continuous Delivery track hosted by Eoin Woods. QCon videos of all the talks should be available soon.

One particularly interesting talk was by Steve Thair on ‘DevOps and the need for speed‘. Previously I thought DevOps was about developers and Ops people collaborating to enable faster software delivery. Steve’s definition went much further and ended up being closer to how I think about Continuous Delivery.

Steve defined DevOps as a model that “encompasses a product-centric view across the entire product life-cycle (from inception to retirement) and recognises the value in close collaboration, experimentation and rapid feedback.” He emphasised that the business and testers should be engaging in the collaboration just as much as developers and ops people.

An interesting distinction between Steve’s DevOps definition and Dave Farley’s Continuous Delivery definition focused on the definition of ‘Done’. Continuous Delivery is defined as being about “making businesses more experimental through the early and continuous release of valuable software”. It appears to be complete once the release is out in production. DevOps adds an important final step of evaluating how much value the release is actually adding once it’s in the hands of users.

I love Steve’s definition of DevOps but unfortunately think this term is sadly restricting. I doubt business people or testers will feel included in something called ‘DevOps’. Even more confusingly I believe there are both devs and ops people who do believe ‘DevOps’ only covers devs and ops.

Even re-defining Continuous Delivery to extend beyond the release doesn’t really help the situation. We’re trying to create a process that keeps the software in a state where by it can be released whenever the business wants it to be. Obviously there are some questions around why the business would suddenly decide to release with little notice and whether we should support that or not. Leaving this aside I think Continuous Delivery is a positive way of working to remove unexpected delays to releases.Any process that encourages collaboration and stress-free releases should be given strong consideration in my book.

A name is always just a name but in the case of improving processes and making sure all roles are covered I think it becomes pretty important. We need to hear everyone’s voice as we attempt to fix software development.The concepts being discussed are important and will affect us all. I personally feel that neither the ‘DevOps’ or ‘Continuous Delivery’ terms are quite right for describing an attempt to engage with all stakeholders and release timely, and functioning software to end-users. Regardless of this I believe everyone involved in software design, development and releases should be involved in deciding the best way to fix the software industry.

What do you think? Are you a Continuous Delivery or DevOps fan?