The Agile manifesto says that 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 our customer's 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.
Then there’s an additional part. Since software doesn’t “end,” even on release, there are going to be future versions of it. It could be next year, or it could be next Sprint, or 50 times a day. “Working” continuously means two things:
- Don’t break anything that has worked before.
- Add some value of the new features with every release.
Working Software Is a Lot of Work
Some of it is DevOps work. However, 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 the 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. 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 a 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. It's more of an ad-hoc, spur 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 how much code to merge and when to merge it. If hundreds of people work on the trunk, we increase the risk, and to mitigate this risk, we’ll do additional work (like set up preliminary testing prior to the merge). Or, we'll split the codebase so that we won’t be stepping on anyone’s code and won't 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 mindset, 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 that we saw earlier. I’m sure you’ll agree that 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.