The agile manifesto says we value working software. What is working software anyway?
We can talk about software working in different contexts. First are the non-tangible parts (more working than software):
- Idea – The ideas for the product we’re going to build need to make sense and solve the our customer problem
- Design – We need to have a proper solution to the problem
- Components – Up to some level of design, the components need to work. We can prove that through unit and integration tests.
Then comes the whole software part:
- Tested – Both for function and the non-functional bits
- Fit for design – Does what we want it to do. This is the insight we get from testing.
- Fit for purpose – Does what the users actually want to achieve, not just what we think they need.
And then there’s an additional part. Since software doesn’t “end”, even on release, there are going to future versions of it. It could be next year, or it could be next sprint, or 50 times a day. “Working” continuously means:
- Don’t break anything that has worked before
- Add value of new features with every release
Working software is a lot of work
And some of it is DevOps work.
But we’re not just going to spell out every skill out there. Instead, we’ll use our agile spectacles to see how DevOps practices help us get to “working software” each step of the way.
Before we do that, let’s check our spectacles. Agile is a lot of things, but all the methodologies try to focus on common principles. We’ll focus on teh following principles:
- Minimize risk – Every agile methodology helps us navigate the seas of uncertainty. We do this by minimizing the risk of taking on full-on projects and implementations. We do it by restricting work in time.
- Minimize waste – The focus on valuable work and continuous improvement in order to reduce waste are also part of any agile methodology. Retrospectives are the key tools there, but visualization and learning from experiments help us as well.
- Early feedback – Without feedback we can’t minimize risk nor waste. And we’d like to get that feedback as early as possible, obviously for the minimization part.
These three principles guide us toward better practices. Let’s see how they help us get to working software, in different stages of the product life-cycle, in DevOps context.
While the ideation and design are essential, until there’s actual development, DevOps practices don’t enter the picture. When they do, we associate them with developer practices, but they are really part of the big bucket of DevOps practices.
- Minimizing risk – Source control, branching methodology
- Minimizing waste – Continuous integration
- Early feedback – Unit and integration testing
Source control is pre-requisite for development, that IT was (and sometimes still is) responsible for. It is worth mentioning, not just because having a repository minimizes risks. As with many things, the tool is not the important part, it’s how you use it.
Enter branching. Deciding on how and when we branch is a DevOps skill. Mostly the decision is not done as part of analysis, more like ad-hoc, spare of the moment thing. However it has interesting side effects.
For example, we can decide everyone will be working on a trunk (instead than on personal branches, for example). This decision has the effect of when and how much code to merge. If hundreds of people work on the trunk, we increase the risk, and to mitigate this risk we’ll do additional work (like setup preliminary testing prior to merge). Or split the code-base so we won’t be stepping on anyone’s code, and not get involved in multiple merges per day.
What’s that? Where’s XP’s “collective code ownership” rule you ask? I’m not saying all development shouldn’t be done by everyone on every code. My point is, that how we do branching, has an impact on development, IT, operations, etc..
Which leads me to continuous integration. The mind set, not the tool. How we continuously integrated derives from the earlier (yet evolving) branching decisions. When we are set on doing CI, we’ll build the needed feedback cycles to do it. CI automation lowers the risk of errors, but also reduces the waste of integration. Combine it with different tests, and we’ve got an awesome set of practices to develop working software properly.
I know what you’re thinking. This is not “real” DevOps practices, it’s just development.
It sure fits the definition of developers collaborating with IT we saw earlier. I’m sure you’ll agree it’s a skill we need on the team, and it doesn’t matter who holds it.
Next time, we’ll continue looking at DevOps principles and practices, as we move on to the testing phase.
| Reference: | An agile introduction to DevOps – Working software from our JCG partner Gil Zilberfeld at the Geek Out of Water blog. |
