And there is a lot more room for things to break down. There’s more that needs to be configured, deployed, tested and checked.
#Spotify qa wordpress software#
Agile software development, on the other hand, encourages the removal of queues. So, DTAP-pipelines encourage the creation of queues. A vicious cycle tends to form as teams postpone deployment in favor of adding more new features. The deployment will take more time, a lot has to be configured and tested on the new environment and there is an increasing chance of bugs and errors. The bigger the pool, the trickier this becomes. In a DTAP-pipeline, the flow of features tends to be like this:įeatures are pooling up in an environment until the team feels ready (or has the time) to deploy to the next phase. But why do I consider it an Anti-Pattern? Why is DTAP an Anti-Pattern? These are some of the behaviors I often observe when it comes to DTAP-pipelines. As new features are added to the batch (the ‘new version’), already tested features have to be re-tested to make certain everything still works. ‘We can’t move X to environment Z because Y is not done/tested/accepted’: The batch-wise nature of how DTAP-pipelines are used encourages teams to see deployments as ‘new versions’ encompassing a whole bunch of features.Teams spend a lot of time dealing with environment-related issues or making comments like ‘It isn’t that slow on Production’ or ‘This only happens on Staging’ This is often further complicated by different configurations of the server and the application, causing bugs and problems in particular environments. But without exception, teams that I work with have to work with under-powered, slow and insecure pre-production environments. ‘This only happens on staging’: The idea of a DTAP-pipeline is that you can test functionality in an identical environment before rolling out to the next phase.Teams spend a lot of resources, time and effort to figure out and keep track of where a feature is deployed ‘Where is this running again?’: Conversations within the team, and especially Daily Scrums, tend to feature a lot of talk in terms of ‘What environment is this running on?’ or ‘Have you already deployed the feature to environment X?’.Administration requires time and discipline Like a Scrum Board with different columns for the different environments (I’ve seen one team with 10 columns), or tag/label-based administration in a tool like JIRA. Complicated administration: In an effort to keep track of what features are deployed to which environment, teams resort to all sorts of complicated administration.Worse, a lot of breaking issues are often discovered on this final day of the sprint Because deployments rarely go the way you want them to go if you have a lot to deploy and you do it by hand, the Fridays will end up being very stressful. This becomes increasingly pressing as the number of environments that need to be updated increases (like ‘Acceptance’ and ‘Testing’). ‘Deploy Friday’: When deployment takes a considerable effort, teams often postpone deployment to the final day of the sprint.
This struggle manifests in several behaviors: I’ve just seen and been in too many Scrum Teams that struggle with their DTAP-pipeline. if you like to listen instead of reading, you can listen to us read this post in our podcast The Liberators Network. In this post, I explain why and what you can do about it. I strongly believe that DTAP - or at least having separate environments for testing (T an A) - is an anti-pattern in an Agile environment. If you are working with Scrum and you have a DTAP-pipeline or DTAP-street (Development > Testing > Acceptance > Production), you have a great opportunity to improve.
0 kommentar(er)
