2

We are delivering a ground up rewrite of a core system with the delivery team working in a Scrum environment. Due to the size of the team we have now split into two scrum teams who aim to integrate code on a daily basis. Whenever the test team deploy to our system test envrionment (daily as a norm), we tear the database down and repopulate all reference data - this is to ensure a baseline for testing.

The problem with this approach is that we are impacting our velocity quite heavily whilst one of the test teams is waiting to deploy a fix and the other is mid test execution. To try and resolve this we have proposed the following:

  • Creation of another test environment (which is quite expensive), in addition we would still encounter delays since one tester within a team is still unable to deploy their fix.
  • An option for code only deployments (avoiding the database tear down).

We try and encourage the team to be cross functional and encourage testers to help the tester out who is blocking the deployment but this isn't always practical. We also aim for tasks to be approx 1-2 days effort so we can't break down the items duration very easily.

What approaches have others adopted in their environments?

Dan Bergh Johnsson
  • 964
  • 10
  • 14
Sidebp
  • 770
  • 1
  • 10
  • 26
  • 1
    If I'm understanding you correctly, you have 2 scrum style dev teams and a separate testing team. Have you considered adding testers to your scrum teams? This should greatly decrease the number of blocking bugs that are found post deployment (and also foster the scrum ideal of delivering "done" software). – Andrew Clear Aug 01 '12 at 18:07
  • I'm voting to close this question as off-topic because, from [What questions Should I avoid Asking?](https://stackoverflow.com/help/dont-ask) in the [help], you should avoid questions where "...your answer is provided along with the question, and you expect more answers: “I use ______ for ______, what do you use?” – EJoshuaS - Stand with Ukraine Aug 01 '17 at 14:24

1 Answers1

2

Instead of tearing down and start over, consider an approach where you "evolve" your database, by formulating each change as a "delta script" which makes both the structural change (add table, rename column etc) and migrate the data.

I have used this approach a few times, and when it has taken hold it has been a great success - enabling both team and each developer to move significantly faster.

If interested, I have a blog post where I describe one of my efforts: http://dearjunior.blogspot.se/2008/05/version-of-data-in-database.html

If you want to get into depth, I recommend "Refactoring Databases"

The team where we got the furthest we developed a truckload of bash scripts to manage everything. However, nowadays there are also some neat frameworks. We have started using dbmaintain which actually is very similar to what we developed ourselves.

I thoroughly recommend this approach.

[Update] I just came across that Software Engineering Radio ran a podcast episode on this topic just a few months ago.

Dan Bergh Johnsson
  • 964
  • 10
  • 14