We all strive to shorten the time-to-market of our software. With this goal in mind we start to automate tests, develop in agile and/or scrum teams, start with Continuous Delivery and so on. All these methods can be successful – can. The successes of these methods depend on your old architecture and infrastructure. We need to innovate the way we use our current infrastructure.
The DTAP architecture we use nowadays hasn’t significantly changed since its inception in the nineties. Software development has changed quite a lot however, requiring us to innovate our non production environments and their architecture.
DTAP and Agile Software Development
A short list of challenges and problems:
- Refreshing a database costs too much time
Requiring anywhere from a few days to several weeks, it can be a costly affair. More so because during a refresh an agile team can’t do anything; they need that database.
- Data is a precious resource
When developing and testing software you’ll need data. Chances are that your agile team has to share its test data and database with several other agile teams. To prevent resource contention you’ll define time slots, which is hardly ideal.
- Test data degrades
Software development and testing will often require you to mutate your test data. Which means that your test data will degrade over time to the point where it will need to be refreshed. This is especially true when working with multiple teams.
Improved situation Agile Software Development
Creating smaller, flexible and durable test data sets will greatly benefit organizations. Developers and testers can execute software and tests on their own test data. Creating smaller test sets also helps in limiting your storage costs, as development and test environments do not necessarily need to have the same capacity as a full production environment.