Question

My group is trying to move over to TFS from our custom-coded build process. Unfortunately, I'm new to TFS build processes and as I dig deeper into creating custom build processes, the more I realize I don't know how to do some basic things. Can anyone help me with the following?

Due to our need to often patch older releases for various customers unable/unwilling to move to newer releases, we're using a branch-for-release model, with programmers committing to the trunk, and a branch created whenever we need to release. That way we can patch an older release should there be any problems.

So I need to do the following:

On queuing a build, input parameters so that we can define versioning, branch name, and information to include.

Programatically branch the trunk and build from that branch.

Any thoughts on the matter? I'm beginning to think the branch-on-release strategy doesnt work well with TFS, so if anyone has a good idea on how to set up the process such that we can make regular releases, but still patch older releases, I'm all ears.

Thanks

Was it helpful?

Solution

Not sure exactly what you're trying to do, but I see two scenarios:

  1. You build from trunk, and branch for safekeeping from each release. In which case I see no problems.

  2. You branch for each release and build from that branch. In which case I would suggest creating a new build definition for each branch (but reusing the custom build process template).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top