At my company we are re-assessing which developers will take on the deployment for xyz ticket. At the moment when a developer is done with his ticket, a deployment ticket is created and another developer will take it, do the code review and test the change(s).

We have 3 databases

  • Development
  • Staging
  • Production

The problem is that we don't really have a real DBA, only someone assigned to validate and run the databases changes. In the development environment we(developers) own the DB and have all the rights, but when we make a ticket for the deployment(which requires the staging DB for testing) we don't have the necessary rights and this is where, i think, there is a problem since we need to create a new ticket to have our SQL changes run on the staging DB and it may take some time before those changes are made. After all the review, test and feedback processes we're ready to push the new changes into production, however we're blocked again and need to make another ticket to have our SQL run in the production environment.

My 2 cents on this is that since developers do the deployment and the staging database is for the deployment we should be the owners and making ticket after ticket is just a waste of time because it slows down the deployment process and has side effects for our clients because new features/bug fixes don't come as fast as they should because we're stuck with ticket after ticket.

Who should own the staging database and why?

1 Answer 1


You say

however we're blocked again and need to make another ticket to have our SQL run in the production environment.

Why? This should surely all be part of one ticket - bug xyz.

What I would do is have the original developer push it out to production and the original tester repeat their tests on the production system (or get the client to do it) and verify that the results are a) bug-free and b) work as the original tester saw fit to pass.

What bug-tracking software are you using? I thought that most of them (all) would consider deployment part of the process for one bug-fix - or that they would allow you configure your system to make that the default behaviour?

  • We use TrackIt for our tickets management and for the bug-tracking it's build-in with our programming language(WinDev) which is more a framework than a programming language imo. I work for a city and we have restriction that's why i said that we're blocked, but i should have said that the administration is blocking us with politics. We're trying to do like you said : all be part of one ticket. Commented Sep 22, 2014 at 18:52
  • Well, if you've no choice, can you not merge the "new" ticket with the old (IIRC, most bug-tracking systems allow you to do this in some shape or form - esp. for dups)? Give the client the "new" ticket number, but you keep the old one on your side?
    – Vérace
    Commented Sep 23, 2014 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.