2

Right now I have an Azure PaaS solution with a single repo in TFS - we right-click publish from VS to an App Service and then swap slots to get code to production. Small team, disciplined check-ins (or so I thought), etc.

I made a decision to check code in that wasn’t production ready, thinking if needed, I could roll back and publish a hotfix should the need arise.

Well, the need has arisen and I've rolled things back to apply the fix. This was a bit of a headache though.

I’m a little unclear on what the right thing to do is moving forward. What I want to try is:

  1. Create a branch from our MAIN repo and stick all ongoing development there, call it DEV. We'll create two workspaces on our machines - one for each branch.
  2. When we're ready to push a feature, merge down to MAIN and then QA before right-click publishing > Staging > Prod.

At a high level, does this seem like a step in the right direction?

What I’m trying to do is keep this project/alm lean and simple. I don't want to go as far as introducing a build server with RM and other expensive (time, materials, process) components - I just want a sensible, incremental upgrade in the maturity of our current setup to avoid the above headache and this is all I could come up with.

RobVious
  • 12,685
  • 25
  • 99
  • 181

2 Answers2

1

That's two way for your reference, one base on the working flow , one base on the publish (releaseing)

A. Just using mainline and tagging for release

Pros:

  • Avoid merge hell.
  • Keeping to the mainline encourages some best practices like proper release planning, not introducing a lot of WIP, using branching by abstraction to deal with out-of-band long term work, and using the open closed system and configurable features for dealing with managing works in progress that may; or may not; need to be disabled now or in the future in order to release or to avoid a full rollback.

Cons:

  • Dealing with works in progress becomes an issue and adds to potential surface attack area when it comes time to release. However, if your developers are disciplined then new features should be configurable and modular and therefore easily disabled/enabled, or there is no WIP and at each release point all work is either completed or has not yet been started (i.e. Scrum).
  • Large scale/out-of-band changes require more thinking ahead of time to implement.

B. Branch by release

Pros:

  • You can begin working on the next iteration while the current iteration finishes its round of acceptance testing.

Cons:

  • Tons of branches.
  • Still need to tag branches at release points.
  • Still need to deal with WIP and merge WIP from previous release branch into next release branch if it's not going to make it and still need to disable or yank it of release branch and re-run acceptance tests.
  • Hot fixes need to be applied to more branches (release branch + hotfix + new tag merge hotfix into vnext branch and possibly vnextnext depending on where the hotfix fails.)
PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62
  • Thanks for this. I like `A` - but if I do create a branch for feature work, do I have to create a new workspace to work on this branch? And how would you recommend enforcing that code can only be published from MAIN (human error of publishing from Dev exists here) – RobVious Aug 25 '16 at 20:14
  • 1
    No, you don't have to create a new workspace to work on a new feature branch. Since there have been a `dev` workspcae to isolate and switch among the changes. About enforcing that code can only be published from MAIN, you can set with permissions. Such as only QA can publish the branch after all test passed. Then you just need to deny the **Read** permission of the dev branch to the user. (better to through command line to achieve this)[Is there a way to make a branch invisible in TFS?](http://stackoverflow.com/questions/10145659/is-there-a-way-to-make-a-branch-invisible-in-tfs) – PatrickLu-MSFT Aug 26 '16 at 02:19
1

With respect to your point 1. I would not recommend using two workspaces, since you already are running "two workspaces" internally with two branches. The approach is not that bad, just a litte hard to do in TFVC, meaning the old server based version control inside TFS. I do hope your planning to merge everything from dev to main at point in time.

In general your guide is more matching with Git as source-control, and especially gitflow http://nvie.com/posts/a-successful-git-branching-model/ as a branching model. We are running that with success within my team.

You can migrate from TFVC to git using git-tf http://git-tfs.com/

If you are looking for a cheap model that scales out with buildservers and such I would reccommend looking at Visual studio team services https://www.visualstudio.com/en-us/products/visual-studio-team-services-vs.aspx as well to host and build your code. There you also have Release management integrated without cost(up to 5 people/free for all visual studio subscribers)

ovebastiansen
  • 61
  • 5