Hi trying to implement TFS for my team (18 members).
I made two branches
1) Main branch
2) Dev branch
We are using Agile.
So there is a sprint every week. And on every Thursday i merge changes from Dev to main Branch.
Each developer works on different user story. if he completes a task and check in all changes (5 files). change set (e.g 62) is generated. But tester reported a bug while unit testing. Developer fix the error and check in 1 file. it generated a new change set (e.g 63).
Problem is when i am merging user story's change to main branch i am confused with which change set to move. (62,63....)
what i do is compare whole project. which is headache some times.
Can some one suggest better way. Or i am missing something? any blog that can help
Thanks
If you have a single DEV branch, that implies that you should be merging the whole branch and all changes to MAIN (not cherry-picking, which is what you seem to be describing).
If you want the flexibility to merge only changesets relating to certain stories/bugs, then you should adopt a different branching pattern such as branch by feature.
You need to change the way that you build and deliver software in order to deliver more successfully.
http://nakedalm.com/avoid-pick-n-mix-branching-anti-pattern/
What you are describing with picking changesets will consistently and continuously reduce the quality of your product.
If you implement a good definition of done and get your guys working in a team rather than independently you should have working software at the end of each sprint. Just before the Sprint review (just in time) you should merge everything from dev to main maybe using a changset as a watermark. If you have stories in your sprint that go towards features that are not ready yet then you should hide them behind feature flags and ship.
If this sounds to hard, or something that "will not work here", or you think "or product is more complicated than that", then you are likely suffering from significant technical debt and you need to pay that back untill you give your Product Owner the choice to release everything at the end of every sprint.
Related
I want to migrate from star team 2005 to TFS 2010 with HISTORY. Is there any tool or any way where I can do it cost effectively. I know about Timely Migration tool, but it is too expensive.
There is no tool out there to do this. You are stuck with paying for Timely Migration or writing it yourself. Capturing history from StarTeam is extremely complex. The reason for this is because of what the view looks like historically. You can roll back the view to a point in time, and this alone works very well, but rolling back to every point in time where a change happened to the view is practically impossible to do using the API. This is because 1) not everything has an Audit record, so you can't use the audits, and 2) the audit records are purged, 3) there is a special feature to "play back" the history of the view to generate the listener events (requires MPX), but this will miss many events, 4) when items are shared, configured, branched, etc., these do not generate any audits in the project, 5) even if they did, getting every single change requires iterating through the view history down to the second to get all of the changes by analyzing the differences. So that means if your project has been active for a month and each time you analyze the two view configurations to diff them it takes 5 seconds, then actually migrating your project would take 5 months, and in the meantime it would be locked down.
So the next way to do this would be to establish "baselines" to compare. Using build labels is a good starting point if you have nightly or continuous builds in your project, or even just certain builds that were QA certified. This way you can use these baselines as points for diff/compare and then bring in the history that way. While this isn't as granular as a full history, it is by definition getting the most important differences to migrate over.
However, keep in mind that even doing it this way does not maintain the links between branch/merge points across the different branches/views. The only way to do this would be to go directly into the StarTeam database to get this information.
I went through all of these steps to try and write my own suite of tools to migrate from StarTeam to Subversion. It was fun and interesting and imperfect but had some promise, but ultimately never finished it. Part of the reason was because the time involved would have been far more than the value I got from it.
Which brings you inevitably to the most important question: what is the business value of maintaining full history? After going through this many times with project teams as a StarTeam administrator, more than 90% of the time it was readily apparent that the better approach is a cut-over. Make a time where you can begin working on new work in the new system and freeze work in the old system. It usually can be done with very little down time for the project team. You can even start by bringing over a history of Production releases to create a rough timeline in the new system. Use your existing comparison tools, either in TFS or BeyondCompare or elsewhere, to reproduce each state of your project source code, doc, etc. and reconcile it with your TFS project by checking in or deleting files as needed, and labeling your TFS project for each build you bring over. Line up all your TFS builds, work items, users, roles, etc, and make sure everything is ready. Then at time of cut-over, take the latest development snapshot from StarTeam over and do one more update to your TFS project. Lock your Starteam users out of the project (for checkins anyway), and begin working in TFS. Your TFS project will have a rough history of the most significant baselines and you will be able to keep your StarTeam repository open to users in case more history is needed.
One other thing to consider is how to create a permanent archive of your project. If your repository is small enough it is doable, but gets more time intensive the larger your project is. First, copy your entire database and vault to a separate instance and get that copy up and running. Then delete all other projects EXCEPT the projects you want to archive off. Run an online purge and make sure to run it to completion. You may need to restart your server and purge several times. When you are done, your entire repository should contain only the files and database records that are needed by your project. At this point you can back up your database and vault and keep them indefinitely. This reduces the size of your existing StarTeam repository.
Haven't used StarTeam in over 3 years but that was a fun ride back in time. Hope you found it useful.
We are starting to work with feature branches and we want to set up a check-in policy that only allows check-ins to the baseline when they have an associated code review.
The new code review workflow in 2012 is quite nice, since you can easily interact with the developer and other reviewers, and comment lines of code directly. Nevertheless it seems like MS didn't think the use case fully because we easily run into the following problem:
The developer works on the feature branch checking-in/shelving and forward-integrating regularly.
When she wants to integrate the feature, she merges back into the baseline and requests a review on these pending changes.
The reviewer makes several comments and now she has to change some code. Where does she do this?
Option 1: Go back to the branch, edit the code and check-in the changes in the branch. Undo the pending changes of the first merge. Merge and request a review again. Repeat until there are no more comments. Check-in the merge.
This is not so nice because all the review comments are in the pending changes of the merge, and she has to work on the branch where she doesn't see the comments directly.
Option 2: Make the edits directly on the pending changes of the merge. Request a review again. Repeat until there are no more comments. Check-in the merge.
If she wants to continue working on the branch, she would have to make a forward integration because the changes from the review are not there.
Either way, the second review is always very annoying, because you have no way of only seeing the changes between the first and the second review, since you are always diff-ing with the baseline.
Am I missing something here? Is there another option that allows reviewing the changes from a review?
Does anyone have a better way of feature branching and code reviewing?
New: Using VS and TFS2013, still no improvements :(
You're not missing anything. This is an unfortunate problem associated with the way Code Reviews were implemented, they can only be linked to one changeset, not to a range of changes.
If your team is used to a high frequency of checkins on their feature branches, then having every individual changeset reviewed using the tool may be a lot of overhead. But that would be my recommendation.
There is a trick, it's not ideal, but it may help. You can check out (on your feature branch) all files that were changed since the last checkin. Then request a review. It will create a shelveset with your changes and associate that to the review. That way you don't have to perform the merge prior to requesting the review. Just make sure you merge the latest version from main into your feature branch before pulling this trick. There are 2 major drawbacks to this:
While all changed files will be linked to the review, the changes since last review won't be highlighted automatically. The reviewer would have to manually do a "Compare to version" and pick the compare target.
There is a limit of 4000 (from the top of my head) files that can be associated to a review, so that may pose a limit to which files you can review as a group (I hope you're not changing 4000+ files between integrations into main).
We are currently using Jira 5.1.6 with GreenHopper 6.0.5. We have a lot of projects, probably about a dozen total but only a few that are actively worked on at a time, with the rest being there for occasional bugfixes or other tasks. The 4–5 developers in our company are likely to be working on a couple projects at once (some working on just one, some working on maintenance on several, and it somewhat varying who's working on what depending on the business priorities).
So, GreenHopper seems set up from a very project-centric view. I can set up a Rapid Scrum Board for a project, and make Sprints within it of work to do for that project. This can give the business a good view of work into that project. Potentially, one can also make a Board for all of the projects (since GreenHopper 6 added that), and make a kind of "global sprint" across everything. If we were to have this kind of global sprint, all of the project owners would need to work at once on figuring out what should get done over the next couple weeks, which might be workable, but seems a bit tricky and would require a lot of coordination.
What I think we want is some kind of "resource view" or something, so that project owners could set up their tasks in their sprints, but there's some sort of view for each developer to tell them what task they should be working on next no matter which project's sprint it's in, and some way for our manager to allocate our time across the projects. So, I might be scheduled to work, for example, 20 hours a week on project A, 10 on project B, and 10 on maintenance of other projects, and then project owners making sprints could see how much time they had allocated, and I as a developer would see some kind of unified view of my upcoming tasks, so that I would know what I should be working on next and what's coming soon. I don't know if that description is exactly what we want, but I think we want something along those lines, and it seems like we can't be the only place that wants some sort of project-based view as well as a resource-based view.
The thoughts I've had of how we might approach this from my exploration of GreenHopper so far are:
Create those "global" sprints I mentioned, and work as a department at the beginning of each sprint to try to schedule what we'll all be doing. Projects can get a look at their particular piece of the sprint using a Quick Filter or somesuch, and we just have to deal with coordinating those sprints.
Use the "Parallel Sprints" feature on an all-projects Board, and have each developer create their own sprints of the tasks they have coming up. This helps with getting a resource-based view, but is probably tough for projects to figure out status of things, and definitely feels like squeezing GreenHopper into a space that it really doesn't want to go.
Create a board for each project of the things to be coming up for each project, so each project gets its own Sprints and we get the project-based view of things, and just have each developer track themselves which projects' sprints they should be getting tasks from. Basically, just GreenHopper isn't the tool for a resource-based view, so don't even bother, and trust our developers and our manager to look across all these projects for what tasks to work from rather than trying to do it all in one place.
None of those seem great, though I'm sure we could make do with any of them. But I keep on coming back to that it doesn't feel like we're doing something bizarre or unique to us, and we would have thought that since Jira/GreenHopper was an industry-standard agile tool that it'd be easier to use it for what we're trying to do. Are we doing something crazy? I think we'd be fine with changing our process to use standard practices if there's a standard way of doing Agile across multiple projects out there. Is there some GreenHopper setting or report or something somewhere I've missed? Is there some other Jira plugin that we should be using instead of or in addition to GreenHopper? Do other teams out there use one of the above approaches and can give advice on whether or not it's a good idea?
Any help would be appreciated. Thank you.
"... seems a bit tricky and would require a lot of coordination." Yup, sounds like project management to me.
I'd create boards for each product that gets released on its own schedule. I'd also create a query to show each user the issues assigned to them sorted by Sprint so they can see what work is on their plate. The issues will be across multiple boards and sprints.
I do wish that GH helped with resource allocation more, including totaling up the time allocated in the filter in the previous paragraph. At the moment I end up exporting the results of the filter to Excel and using that to sum up totals by resource.
I asked this question in perhaps the more appropriate place, on the Atlassian forum:
https://answers.atlassian.com/questions/99020/how-do-i-use-greenhopper-to-manage-developers-across-multiple-projects
And I think the answer there from them was very good. I created a board for each project, limited to its project and used for creating that project's sprints, and the developers use an "All Projects" board to see all of the sprints that they're a part of.
Doesn't handle resource allocation wonderfully, as mdoar states, but it does seem to be using the tool the best way that it can be for this for now.
My scenario is pretty straight-forward. I am working on a long assignment locally on my computer, working off of a code branch from TFS. Along comes the boss, and I need to push through a bug fix. Is there any clean way to change contexts? This long assignment has updated a lot of files, and I want to make sure I implement the bugfix from a clean slate.
If I were using Git, I know what to do: create a new branch from main, fix bug, check in, change back to previous branch, but TFS doesn't really work that way. Any ideas?
If you don't want to commit the changes you 're working on yet, your first step is to shelve them - that's pretty straightforward.The next step is to decide where you 'll be implementing your urgent request. This depends on
How you have set up your branching scheme in source control (see here for a great resource ), &
The line where the error was reported
'Boss'-bugs tend to be reported from Release-Lines, taking this as a given you would have to:
Identify the latest changeset that corresponds to the version your problem was reported
Track this changeset to a version in the branch you can work on (I suppose you can't make changes directly on your release line, right)
Make a branch & implement the change. Your build-environment should ensure that all tests & checks ensure that your issue is fixed & that no others have emerged.
Your next challenge is how you 'll propagate these changes to a new Release - This greatly depends on how you ship software to the customer (Hotfixes? Patches? Service Packs?), as well as the severity of the issue.After you 've settled everything back to normal, unshelve & continue working on your long-term task.
Currently I am working on a project that uses TFS as source control. I am in the middle of implementing a piece of functionality, but am blocked by work that needs to be done by outside resources. Since the functionality is not fully complete, I can't check in the changes without breaking the build. So instead of waiting a couple days while the blocking work is finished, I want to work on some defects.
To do this work in isolation from my other changes, I am working the defects in a second workspace I just created.
After using a second workspace to isolate my changes, a coworker asked me why I didn't just shelve my changes. After doing some reading on shelving, it looks like this is preferred solution to situations like mine. My question is what situations, if any, would you create multiple workspaces and what situations should you use shelving? There are some posts about shelving, but I don't see very much on the subject of workspaces.
By the way, I got the idea for creating a second workspace here.
A new branch would probably be the best way to go. But, to answer your question, one of the key differences between shelving and just using a differnet workspace is that when you shelve, you push your code back to TFS, so it is backed up. Whatever is in your workspace is just what you have on your machine -- if you lose it, it's gone.
We use branching a lot in my shop, and as a result, I haven't seen many uses for shelving.
However, I have found one case where it has been very useful to me:
I often bounce between 2 different development machines (one at the office, one at home, connected via VPN). If I am working on something, and I want to transfer it from home to work, or vice-versa, I often use shelving. I can shelve it from one machine and un-shelve it from the other. I do this when I am in the middle of a change, and checking in would break the build or otherwise interrupt other developers.
You are talking about two completely different concepts here. When you shelve code, you are saving it to TFS, but not checking it in to any particular branch. Creating a different workspace just sets up a new local folder on your development machines and saves the files in your branch there. When you do a check-in, you still could have conflicts.
Why not create a new branch of your code. You can work on that branch and check in without stepping on anyone else's changes, because you are checking in to your own branch of the code. Then, when you have completed your changes, and others have completed their's on the main branch, you can merge your changes into the main branch.
Shelving is the ideal option. Shelving allows you to make changes en masse in TFS outside the regular build, and retrieve them later by name. Multiple workspaces is not a solution for what you're doing. Multiple workspaces are good if you're maintaining different versions of a product and need to work on them, e.g. let's say you have a 4.0 and a 5.0 product and need to apply a security fix to both versions. Shelving is great when you want to make changes but not commit them immediately.