CODEWITHSUNDEEP
svnversion-controlcontinuous-integrationbranchbranching-strategy
Jason
Jason

Reputation: 4705

Branching strategy for parallel task-based development

We have three environments or website (dev, staging and production) on which runs a version of our ASP.NET application. We use SVN and continuous integration (Teamcity) to help automatically deploy the application to each web server.

Our current development workflow is based on a task (or work order) system. A developer is given a task which he has to complete. Many developers can work on the project at the same time, but on different parts of the application.

My current solution makes the developers create separate branch for every task. When a user commits the trunk source code is compiled and deployed to our dev web server.

Developer 1 starts a new task and creates a new branch, let's say "Task 1", from the trunk source code.

He commits his code to his branch and then merges the branch with the trunk.

His changes are compiled with the rest of the code and deployed to the dev web server.

Developer 2 starts a new task and creates a branch from the trunk (with Dev 1's changes).

He then makes his changes, commits his code to "Task 2" and merges the branch with the trunk.

The code is once again compiled and deployed to the dev web server.

Developer 1 is not done yet, but the changes Developer 2 has made are ready to be deployed to production.

Dev 2 then merges "Task 2" with the "Production" branch.

And here is the problem. A part of the changes made by Dev 1 are in production and this is a BAD THING.

I need to find a branching strategy that would allow us to continue the development and implement each task one by one.

Do you have any suggestions? Is SVN the right tool for the job?

UPDATE

I am now thinking of making a "Dev" branch to deploy to our dev server and keep the trunk clean and synchronized with our "Production" branch. This particular problem seems to go aways this way because every developer will create his branch from a clean trunk instead of one with some developer's modifications.

Upvotes: 1

Views: 987

Answers (1)

Windy
Windy

Reputation: 1112

I'm a little confused after I read through your question. If Developer 1 is not done yet and is not ready to have his previouse modification compiled and deployed to the production, it's not a good idea to merge Task 1 to the trunk.

How about this: Every developer creates his/her own branch "Task i". Then, they can work on the branches at the same time. Doing check in, check out, etc. After completing their tasks, they can merge their braches back to the trunk. This way, you can ensure the project on your production server is complete, not part of one's job.

Upvotes: 1

Related Questions