We’re rewarding the question askers & reputations are being recalculated! Read more.
    Tweeted twitter.com/#!/StackProgrammer/status/498187111980630016
2 added 109 characters in body
source | link

I am working in an organisation with 11 scrum teams developing on the same code base. Currently, all development is done in trunk, and at the end of a sprint everything MUST be releasable, or it must be backed out (an arduous process) as a release is cut.

My opinion is that while work in a sprint is (ideally) 'done' at the end of the sprint, this doesn't necessarily mean ready for release. IfYou may be at a point where you do not have a Minimum Viable Product to release, but have some stories complete. If a story is not done, or the story is only part of a larger feature, it should be easy to keep this separate from the release ready code. At the moment it is all backed out, the release cut is taken, then it is checked back in. A huge waste of time!

We use continuous integration, which is the main argument for everyone developing on trunk. Occasionally teams use a team branch, but this is currently frowned upon.

I've been considering simply having a 'dev' and 'release' branch, and pushing features to release when they are completean MVP, andor having a branch for each story or feature, but this is very admin heavy in TFS. Have other people dealt with similar issues in the past, and what are your thoughts on the best way forward? Unfortunately, we are tied to TFS in the short term.

I am working in an organisation with 11 scrum teams developing on the same code base. Currently, all development is done in trunk, and at the end of a sprint everything MUST be releasable, or it must be backed out (an arduous process) as a release is cut.

My opinion is that while work in a sprint is (ideally) 'done' at the end of the sprint, this doesn't necessarily mean ready for release. If a story is not done, or the story is only part of a larger feature, it should be easy to keep this separate from the release ready code. At the moment it is all backed out, the release cut is taken, then it is checked back in. A huge waste of time!

We use continuous integration, which is the main argument for everyone developing on trunk. Occasionally teams use a team branch, but this is currently frowned upon.

I've been considering simply having a 'dev' and 'release' branch, and pushing features to release when they are complete, and having a branch for each story or feature, but this is very admin heavy in TFS. Have other people dealt with similar issues in the past, and what are your thoughts on the best way forward? Unfortunately, we are tied to TFS in the short term.

I am working in an organisation with 11 scrum teams developing on the same code base. Currently, all development is done in trunk, and at the end of a sprint everything MUST be releasable, or it must be backed out (an arduous process) as a release is cut.

My opinion is that while work in a sprint is (ideally) 'done' at the end of the sprint, this doesn't necessarily mean ready for release. You may be at a point where you do not have a Minimum Viable Product to release, but have some stories complete. If a story is not done, or the story is only part of a larger feature, it should be easy to keep this separate from the release ready code. At the moment it is all backed out, the release cut is taken, then it is checked back in. A huge waste of time!

We use continuous integration, which is the main argument for everyone developing on trunk. Occasionally teams use a team branch, but this is currently frowned upon.

I've been considering simply having a 'dev' and 'release' branch, and pushing features to release when they are an MVP, or having a branch for each story or feature, but this is very admin heavy in TFS. Have other people dealt with similar issues in the past, and what are your thoughts on the best way forward? Unfortunately, we are tied to TFS in the short term.

1
source | link

Managing 'done' but not releasable code in TFS

I am working in an organisation with 11 scrum teams developing on the same code base. Currently, all development is done in trunk, and at the end of a sprint everything MUST be releasable, or it must be backed out (an arduous process) as a release is cut.

My opinion is that while work in a sprint is (ideally) 'done' at the end of the sprint, this doesn't necessarily mean ready for release. If a story is not done, or the story is only part of a larger feature, it should be easy to keep this separate from the release ready code. At the moment it is all backed out, the release cut is taken, then it is checked back in. A huge waste of time!

We use continuous integration, which is the main argument for everyone developing on trunk. Occasionally teams use a team branch, but this is currently frowned upon.

I've been considering simply having a 'dev' and 'release' branch, and pushing features to release when they are complete, and having a branch for each story or feature, but this is very admin heavy in TFS. Have other people dealt with similar issues in the past, and what are your thoughts on the best way forward? Unfortunately, we are tied to TFS in the short term.