We have become increasingly focused on developer experience (DevEx) assessment. Possibly because of the continued penetration of DevOps practices and the need to assess the software team members’ mutual welfare, possibly because of the rise of platform engineering and its drive to orchestrate cloud-native systems with increased levels of automation… or possibly just because it matters, we’re now altogether more focused on how well the application and data teams are supported as we equally amplify our reliance on digital services. Where then should the source of this analysis stem from?
Creating positive fluid movement (pun intended) all the way down through the software lifecycle starts with appreciating that applications begin, exist and end in a deployment pipeline.
Down the pipleline
Lead technical content creator at software delivery automation specialist Octopus Deploy Steve Fenton says that – in his world of Continuous Deployment & Continuous Integration (CI/CD) if not elsewhere – there is a need to consider the full length and breadth of the software pipeline as an engineering entity that can be shaped and channelled in order to get our software applications to where they need to be.
In a software pipeline built for good DevEx, he advocates systems that enable the team to change aspects of the environment, tooling and collaboration techniques to intentionally improve feedback loops, reduce cognitive load and create opportunities for flow state.
PSI – productivity, satisfaction & impact
“DevEx is effectively a localised socio-technical study that organizations use to try and improve developer productivity, satisfaction and impact,” stated Fenton. “But rather than operating social experiments on developers as if they are lab rats, the ideal approach to DevEx is participative. You’re more likely to see the benefits when everyone understands the goals and can contribute ideas. The developer-focused elements of DevEx are productivity, satisfaction and impact. These create the initialism PSI, which is easy to remember as reducing the pressure on developers will help improve all three of these dimensions.”
Drawing experience from the Octopus Deploy customer base (the company name being an obvious reference to something so capable of juggling multiple tasks that it effectively had eight arms and hands), the team suggest that a developer is only truly productive when it’s quick and easy to change the code. A developer won’t be productive if the code is hard to understand, changes get stuck for hours in the review process, or they need to get permission from a code owner or architect to make a change.
“Developers are satisfied when they work in a healthy environment, have effective workflows and can use tools that make their jobs easier. If they have to perform repetitive manual tasks or have to navigate a frustrating workflow, it will lower their satisfaction,” offered Fenton, in what may be a plea to make upper-tier project managers more aware of the needs of the code team’s daily challenges. “A developer can make an impact when they can take an idea smoothly to production with minimal friction. If their changes take too long to reach real users, they lack a valuable short feedback cycle and end up overlapping changes to the original task with new work they have started while waiting for feedback.”
Start with the baseline
A professional with some years of experience in this business, Fenton laments the fact that he has had to work at the process of ‘fixing broken development teams’ many times. From his perspective, after checking essential baseline practices (such as version control), the area that brings the greatest change to DevEx is the deployment pipeline.
Why is this so? Because, he explains, the key to using the deployment pipeline to start a DevEx journey is that it improves the developers’ lives while gaining business stakeholders’ trust. When the business function is more confident in the IT team’s ability to deliver software, the suggestion being made here is that their behaviour changes in ways that improve developer happiness. Could or would the business function actually start to regard the IT department as something rather more than a faceless supply line for apps and services? It seems hopeful, but almost too much to ask for doesn’t it?
“For example and to validate this positive behavioural proposition, a solid deployment pipeline reduces the pressure around deployments, provides more frequent opportunities for the business to re-prioritise and eliminates the need for big plans and status updates,” said an upbeat Fenton. “There are tools involved in this activity. A deployment pipeline needs a strong ‘build server’ and a tool that makes deploying software versions to each environment safe, reliable and repeatable. On top of the tools, teams need to work in smaller batches, use continuous integration and deploy more frequently.
Deployment automation
This all leads us to the topic of deployment automation. The discussion here moves to the idea that software delivery throughput and stability improve when an organization automates the deployment process. This means, in theory at least, that it can also use the opportunity to simplify its application and services change approval process. According to DORA research, a simpler change approval process helps improve software delivery performance. Instead of email or wet signatures (i.e. real world ones made with ink), an organization deployment tool can include a manual approval step or even automate approval based on a test.
“By automating the deployment process, you capture the steps to make them repeatable,” explained Octopus Deploy’s Fenton. “Manual deployments are unreliable; you can miss out a step any time the process is executed. If the process is complex, developers will use a lightweight or ad-hoc process to deploy to test environments. This means you only test the real deployment process when deploying to production. When you automate deployments, it is natural to use the same process to deploy to all environments, as it’s quicker and easier than a manual process. This means the deployment process is tested as often as the application code. The deployment process will be more reliable, making it easier to deploy to production more frequently.”
The logic on offer is simple enough to reason and grasp i.e. when a business deploys more often, it can include fewer changes in each deployment. This realistically reduces risk because smaller batches have fewer changes (and less risk) and shorter wait times for feedback help the software team spot problems earlier and change direction.
Once again suggesting that we might be able to look forward to happier times in the post-DevOps era of euphoric workplace harmony, Fenton is of the mind that we might see the commercial business end of an organization adjust its attitude and behaviour towards the software team. If and when a business has found that building an automated deployment pipeline works well for them, there are two possible directions to think about next.
Two possible futures
“You always have the option to improve the deployment pipeline. There might be an automated test you could add to catch problems early or something you could do to speed up the process to get feedback faster. You want your initial build process to complete in five minutes and include a set of tests that gives you the confidence to deploy the application to test,” said Fenton. “Alternatively, the second opportunity to gain a positive spiral is observability. If your development team can detect and respond to a problem before a customer reports it, you can improve relationships and culture further.”
Although not every enterprise technology deployment will ‘fit’ inside a deployment pipeline in the way described above, all deployments will arguably always feature enough of start, middle and end point to align towards some of the theories posited and presented here.
DevOps specialists and DevEx specialists rarely start their consultancy conversations with – okay, tell me about your deployment pipeline – preferring instead to either look at granular code issues (DevOps) and touchy-feeling human workplace issues (DevEx) instead. Perhaps a more considered approach would be to consider the software pipeline as a guiding channel that embodies all technical entities and possible waste products too.
Pipelines are important, please make sure you flush. Now, wash your hands.
Free image use: Wikimedia Commons
2 days ago
