When you are going to release a build using TFS, what do you normally do? Just use a specific changeset, create a branch or label/tag?
Note: this build is not for release, it is for our staging/user acceptance environment.
When you are going to release a build using TFS, what do you normally do? Just use a specific changeset, create a branch or label/tag?
Note: this build is not for release, it is for our staging/user acceptance environment.
The build system will automatically create a label based on the name. Usually that is good enough for most companies.
When we start development on a new version we branch and put new code and revisions in that branch.
This allows us to do two things:
I use a pretty simple formula for deciding if it should be a label or a branch, if there is any chance you'll need to patch or hotfix the build then use a branch. Otherwise, if you'll just want to refer to the code at a certain point use a label. Another important consideration is that labels only have limited configuration manager, e.g. they can be deleted or modified by anyone with permission without any change history.
I actually have more than one build. I use the Versioning tasks that come with the free MSBuild packages (the MSBuild Community tasks, MSBuild Extension Pack and MSBuild SDC) to change my version in Team Build and in my binaries.
I have a custom version that is of the format 1.2.3.4 (major.minor.revision.build)
My nightly builds up the build number. When I am going to do a release to testing I fire off a build that will up the revision number.
Then when you are ready for prod you can release the version that has passed testing.
I would suggest doing nightly build as suggested above by @Vaccano or you could do continuous integration. You can find good build tools to get you off on right direction at http://www.newagesolution.net/SpecialEvents/SessionatOrlandoCodeCamp2009.aspx. There should be Powerpoint and code samples to achieve automated build and packaging.