Merging GitFlow and Pull Requests Together into One Process - Part 1

Recently I was challenged with coming up with a process that enabled the use of GitFlow and Pull Requests.  We were using Jira and Stash/Bitbucket with Visual Studio and SourceTree or command line locally.

Initially this was working fine until an additional requirement was added that only merges via Pull Requests were to be allowed for getting work on the Develop branch.  Because of the permission change you could no longer Finish Your feature and push your merged changes from your local develop branch up to the origin.  You would get a nice permission denied message.  I search high and low and could not find anything out there with a solution.

This is the process I came up with to manage feature work.  I will have some additional posts on managing work for Releases and Hotfix branches.

1. Start feature branch from your JIRA ticket.
1. Leave as a Feature branch type
2. Name of branch must be JIRA ticket (CHI-7)
3. This is equivalent to GitFlow Start Feature
2. Checkout this new feature branch locally
1. Assumes you have already checked out Master and Develop branches for this repository
2. Assumes you have initialized GitFlow locally for this repository (after checkout of Master AND Develop)
3. Commit changes to feature and push to the origin
4. Create pull request for feature to develop within Jira
1. Optionally you can do it in Bitbucket or in Step 3 as part of the commit (see options in SourceTree Commit)
5. Another person performs code review
1. After it meets their approval they will Approve the pull request in BitBucket
2. They will not perform the merge.  This is left to the person who initiated the pull request.
6. Before performing the Merge in BitBucket do a Finish Feature in SourceTree.
1. The goal is to only merge to Develop and delete your local branch
2. Don't do it via Visual Studio or Command line as it will delete the remote feature branch and the pull request will be cancelled. 
3. In VS there is a checkbox to delete remote feature branch so just don't check it.
7. Merge pull request in BitBucket
1. Check option to delete source branch after merge
2. The feature branch will be cleaned up on the origin only
8. Cleanup local repo
1. In SourceTree on Develop you will have your commit still.  Since you committed in BitBucket in step 7 we need to gracefully cleanup your local workspace
2. If you try to push you will get denied since this commit is not via a pull request or saying you can't push because you don't have latest from origin/remote
3. Do a Pull and check Rebase instead of merge
4. This will sync local with remote and the FEATURE WILL BE FINISHED!

The process in visual form.

Let me know if you have any questions around it!

Default Access in TFS Requires a TFS CAL

When adding new users to TFS be careful.  Adding them to a team sets them with the Basic (default) access level.  This means you need to be proactive when adding any users to TFS. 

Make sure you move them into the appropriate AD group within your Access levels

del.icio.us Tags: ALM,TFS Tips,TFS 2013

before you add them to a team.  Otherwise you will end up like me having to take away features from someone who was like “cool I like that feature.”  In my case they were just a stakeholder.

Ensure you do this so when true up time comes you are not paying for CALs when you didn’t really need them.

Using TFS 2013 Update 4 License Change for Agile Teams

We are in the process of upgrading to Update 4 and were figuring out how the license changes affect us (was hoping for costs savings.)  They don’t and probably won’t save us on MSDN costs.  Read on to see how it could save you.

Development

All of our developers and testers have an MSDN Premium or Ultimate.  This covers them not only for TFS but also access to all there test environments and whatever software they have installed.  They will remain at the Advanced access level.

Product Management

The next layer of user is the product owner.  Our product owner sits with each team and helps to manage and groom the backlog.  They also validate work is done which means they use development environments.  That being said they will continue to need MSDN Premium.
I was hoping we could drop them down to Basic (TFS CAL) but the environment thing stops that.  With Basic access a product owner could plan and prioritize user stories for their team but not features.  I guess features is what Microsoft deems advanced planning.  This would be a big cost savings to some companies.
Our next layer is product manages themselves.  While they don’t hop on the development environments that still need to be able to plan and prioritize at the feature level.  With Microsoft’s new license structure nothing changes for us.  Again to get just that feature requires an MSDN license.  That is pretty costly unless I can get them to use the feedback or storyboarding features.

The Stakeholder

This access level is free and allows the editing and creating of work items.  If your product managers are willing to do some work in Excel this will provide your company with some cost savings. 
They can prioritize by using the Team add on in Excel.  To do that just have a query of the features and make sure the Stack Rank is one of the columns.  They can then modify the stack ranks to prioritize the work items.  Once that is done a publish up to TFS will update it for the teams to work from.
This could become cumbersome as working with the stack ranks is not easy for a large number of work items.  The PM’s at my company need to be able to work fast so this will not fly.  Hopefully some one else out there will be able to do this and same some $$. 
Happy ALM’ing!

del.icio.us Tags: TFS Tips,TFS 2013,ALM

TFS Work Item Recycle Bin

Sometimes end users create test cards (stories or tasks) or cards are no longer needed.  Story or feature cards there is no removed state.  This only exists at the task level.  This can result in some inaccurate reporting or bad queries if your not careful.  Plus as an administrator I don’t want to be constantly destroying test cards.

Windows and other applications have a recycle bin.  So why not TFS?  To solve for this an Area and Iteration Path called Recycle Bin was created.  Now we can set any standard queries or reports to always exclude that iteration & area.

del.icio.us Tags: ALM,TFS Tips

Planning with Iterations

One of the things some of the teams would like to start using is the planning feature in TFS.  This feature is enabled on the Stories backlog.  Over on the right there is the Forecast option.  Just turn this on and set the velocity to your teams.  Currently this is a manual task and you will need to determine what velocity to use (last sprint, an average, etc.)

Once this is set you will see a line break with the iteration in the backlog.  This is useful for your planning meetings as well as forecasting how many iterations will be needed to complete a feature (all user stories done).
The question that our team had was how many iterations do you make visible/available for planning into the future? Initially I thought having to many future iterations would clutter things so I created them but did not make them visible.  Unfortunately this does not help the end user as those iterations don’t show up for planning purposes.

Going back into the admin page for the team I then selected all of the iterations I had created.  Thus making them visible for planning.  Now we can see all of the iterations and the team was able to forecast how many until this epic would complete.

Currently we are going to try out 2 week sprints and see how that goes.  I have read others doing three weeks but as a friend told me it is much easier to think about what you can get done this week and next.  This keeps things focused and easier to manager.  We will see.  Thanks for reading.
Are you able to plan out 2 weeks ahead what your going to do?

del.icio.us Tags: Iterations,TFS