Question is about organizing dev environment for the web development.

  1. There is 2 things to deploy: web site and database schema
  2. We use SVN to keep track of source code
  3. We use RedGate tools to generate migration SQL and to version-control database schema.
  4. It is important to have fresh copy of data in our dev environment.

At first, we just worked each in personal databases. Now our team getting bigger so we have dev server with shared database.

For customer, we created "test" website that we run on our server. And it points to our dev database.

For data - we bring fresh copy of database weekly, so it's just another PITA because we do it by backup/restore and obviously schema different when we bring it back.

Where we have problem now is when we release something for customer to test. They check, it may take some time. By the time they check we might already have some other new features added to TEST site. Now, let's say production missing A, B, and C features. Customer tested A, but B and C need to be tested or changed. A need to go to release.

In big companies were I worked there was DEV, TEST and PROD environments. Pretty much DEV->TEST didn't go unless TEST->PROD happened. This caused just wasted time (realistically). Now we can't afford just sitting, so how do we work fast-paced like this with minimum hickups.

Now because we still waiting from a customer on feedback on "A" - we already "forgot" what else we added. With many people it just get's more complex.

So, I guess question is: How to manage DB/Code version control and separate features publishing in such environment? With minimal bureaucracy.

2 Answers 2


This is a difficult problem.

You can try to solve this by using feature branching - each new feature is developed in its own branch independently from the other features. You can then have "test" branch where all of these feature branches are merged so that customer can test all features at the same time . When feature A is ready, but B and C are not, you can then create a build only from ready features, in this case A because it is independent from the other features.

So this is theory, but in practice it doesn't work so well. Smaller problem is that you use SVN which supports branching, but working with them in SVN is kind of a PITA. Some distributed VCS would be better (Git, Mercurial, ...). Bigger problem is that features are often not independent from each other (there may be some dependencies between them, several features touch the same code etc.) and it's just not possible to deploy just feature A, especially without specific testing for this build - even though A worked on branch with all feature branches merged, it (A) doesn't necessarily have to work if deployed in isolation ...

Other possibility is non-technical - have some development/release cycle - e.g. SCRUM mandates that after each sprint you have potentially deliverable product. Also working closely with customer (product owner) for testing, making sure she understands how you work so she can align herself to your development process for greater gain ...


As you also said, the efficiency of the team is not likely to get improved if you only have a TEST environment, where all developers work. I think this is the main bottleneck in you development process.

Every developer should have his own DEV environment in his local machine, with its own database (perhaps a recent clone from TEST environment). So, each developer could work on its own feature independently. When each feature has passed the DEV stage with local testing by the DEV team, it should be commited in the Versioning Control System you use and then it should be deployed in TEST environment to be seen by the client.

In aspects of Versioning, the best practice is that each developer creates a new branch for each new feature and when the feature is to be deployed in TEST, the branch is merged in the trunk. So, all conflicts between different features will be easily observable and by looking the Versioning history, the features added at each step will also be easily noticed, since you will just have to look for merged branches

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.