Different developers check in the code touching the same file or different branches could be getting merged. I am new to TFS from the admin side but I do know how to do basic check-in of the code. How can I avoid the code collision from admin side? We are using Microsoft Team foundation server as version control.
Version control systems are made to allow different users to edit the same files and so that when merging, it provides a reasonable experience upon merge. The ability to check out the same file by multiple developers is one of the things that allows teams to become highly productive. When multiple versions of the same product are being developed or maintained, it's impossible to prevent conflicts altogether.
There is a lot of additional guidance available through the ALM RAngers' guides. I highly recommend you and your developers read this.
Note:
Visual Studio 2013 offers a much better merge experience than older versions. 3rd party tools like Semantic Merge further improve the experience by parsing the code being merged and applying some additional intelligent logic to prevent conflicts.
For certain notoriously hard to merge files, like SSIS packages, there are additional specialist tools such as BIDS Helper Smart Diff.
Some things you can do:
Make sure developers communicate
Teams that do a daily scrum (stand-up meeting) or have the ability to use Team Rooms in TFS can signal intent and keep others up to date on what they're doing pro-actively. Making sure that there is a dedicated communication channel available and that the users have the Team Rooms extension installed in case they're not co-located. Communication prevents many of these type of issues and is the best solution once such a merge issue occurs.
Have developers perform a get-latest and check-in frequently
While there is no server setting for this, having your developers trained on branching, merging and general source control patterns can help a lot. If a user regularly checks for incoming changes (get latest) and checks in as soon as he is relatively confident about his code (say after the first test passes when using TDD), then chances of conflicts is substantially lower.
The Incoming Changes Lens
Codelens has been updated with a new Lens as one of the updates that was released after RTM. The lens requires both the Client and the Server to be upgraded to at least Update 2 and at least Visual Studio 2013 Ultimate Update 2. It's recommended that when you start applying the Updates, you always stay current, thus I'd recommend you install Update 4.
While Code Lens is an Ultimate feature, it will be moved into Professional with the release of Visual Studio 2015.
Use Exclusive Checkout
If users use the Checkout and lock option to check out a file, they can signal other users that the file is undergoing major changes. This feature requires that all users have their workspace type set to "Server Workspace". Local workspaces, given their disconnected nature, ignore the Lock flag. Though individual users can always override their workspace type, it is possible to set the default workspace type at the collection level.
Disable Merging and Multiple checkout for individual file types
A better solution is to mark file types that are hard to merge, the old style SSIS packages with lots of XML and GUIDs are agood candidate here. Open the Source Control settings and add the extensions of "bad files". This setting applies partially in Visual Studio regardless of the workspace setting (Visual Studio will only offer Take Local or Take Server and will not offer to merge.
Disable Multiple Checkout
It is possible to set the Project's Source Control option not allow "Multiple Checkouts", this will automatically acquire a Lock when a file is checked out. It's not recommended to turn this feature on, as it introduces a lot of frustrating things while working in Visual Studio (most importantly when adding any file, one has to acquire a lock on the project file). As with Exclusive Checkout, this requires all users to use Server Workspaces.
As this feature will prevent any file from being checked out by multiple people, it's often trying to apply way to much force to solve this issue. Only in case your developers mess up on a high frequency, you may enable this feature temporarily while they receive training.
Related
What we know:
Tfs allows us to manage bugs. We can add bugs and move it through different states.
What we need:
We need to have different states in bug, which TFS 2015 doesn't allow out of the box, particularly
"Not a Bug" (which is after NEW > ACTIVE and then if Developer says, its not a bug)
"RE-Opened" (where a bug has traversed from NEW > ACTIVE > RESOLVED > CLOSED and then Re-Opened in another Release / Sprint).
Which approach mentioned below we could use ?
A- We are currently on TFS 2015. We do the customization through WITAdmin approach (https://www.visualstudio.com/en-us/docs/work/customize/add-modify-field ) and it's impact on Database, Reporting and going forward, towards migration would be another effort.
B- We migrate our TFS 2015 to TFS 2017 and get the new feature of adding our new states out of the box as per (https://www.visualstudio.com/en-us/docs/work/process/customize-process-field#add-a-custom-field)
C- We need to change our practice of logging bugs, and we need to study proper Agile Implementation through TFS, since AGILE process does have this scenario of What We need mentioned above.
A,B,C are the approaches, I have thought about. I would appreciate if the experts could share their experiences, thoughts and / or new approaches.
The "States" that you want to add should not be States, but at most "Reasons". You will find default reasons set that are close to what you want out of the box.
Since for the Agile Planning tools to work you need to have the same states for Bug as either User Story or Task depending on your configuration there are much wider ramifications to adding additional states. Try and avoid it.
Use A to add additional Reasons for specific transitions, and focus on C for the long term.
Approach B only exists in Visual Studio Team Service, TFS 2017 doesn't have this feature currently.
Approach A will be a good option. But you might need to modify your custom process for the wizard to run, or you might have to update your team project manually after a TFS upgrade.
Check more information of Maintenance and upgrade implications (TFS) on the website below, which tell us what should we avoid during customizations:
https://www.visualstudio.com/en-us/docs/work/customize/customize-work#maintenance-and-upgrade-implications-tfs
We have TFS 2013, currently for the team project working we don't have any branches, basically just a plain folder structure with various solutions in them.
With the goal to introduce release management, the intention is to create several branche, e.g. development/main/releases
As I was told I cannot 'disturb' the project team developers from their day to day work since there are other projects being worked on, question, what is the best practice to do this? Create a separate team project? How can we adopt the branching practice without asking all the developers.
Please help point a direction for this or share some thought on this, any help is appreciated!!
Unfortunately to do this you'll have to "disturb" the development team. You have 2 options. 1. Come up with a process in isolation and then disturb them when it goes live. 2. Collaborate with them on a process and work together to meet your requirements. (Being able to release your code to production is a key requirement for any project, sadly it's so obvious that it never gets added to the backlog / project plan and is always treated as a afterthought)
I recommend option 2. Without collaboration you're just going to end up causing resentment that you're imposing something on the Devs and they'll fight it tooth and nail. Also without the development team being involved you'll miss something important that will make the process brittle and difficult to maintain.
You'll need to get buy in from the Developers to implement a branching strategy as it will have a significant impact on them, they need to understand why you're doing this and what the benefits are, both to them and the business. They don't necessarily have to do any of the work, but they need to know what you're doing and why, they will also need to know when the changes are coming so that they can plan for the change.
Firstly you need to real the ALM Rangers version control guidance.
Secondly you need to get the developers to read it as well. They will be responsible for maintaining the code and merging it between branches. They will need to know when and where they need to check in various changes (such as hotfixes), and what process they should follow when code is ready for release.
Finally, regarding your question about where the branches should be located. It would be better to locate the all branches in the same Team Project rather than having your Dev branch in a separate Team Project.
everyone.
This is my very first question here, so I apologize in advance for any violations of protocol.
We have recently moved to VSO/TFS for source control of our code, and all of us have multiple computers we work on, the usual desktop/laptop combination.
I would like to know what the proper and best practice is for switching computers mid-work. We have been using the Shelve option, but it seems cumbersome and not exactly meant to be used in this way, when all that needs to happen is the switching of computers.
I have personally tried mapping my workspaces to 3 of the major cloud-storage solutions, Dropbox, Box, and OneDrive for Business. All 3 have problems with "perpetual" syncing and slow syncing. What I mean is that they cannot seem to handle the constant file changing that is happening when Visual Studio is happening, and these services don't provide good options for syncing only certain folders.
We really want to keep the workspace mapping in its default location and use the VSO/TFS system to move the code around the machines, but obviously without checking in incomplete work.
Is Shelving the correct practice for this scenario?
Many thanks.
Yes, shelving was intended to handle this type of scenario.
Another option is to use a Git-backed Team Project; you can then work in a local branch and publish that local branch if you need to swap PCs.
Ideally, however, regardless of the type of version control you're using, you should make small, frequent commits to source control as "checkpoints".
I am currently creating a business case for rolling out TFS 2010 as our source control and bug/release management tool.
We currently use OnTime for our bug tracking software and subversion for our SCM.
I was wondering what advantages TFS 2010 has over OnTime?
I have done some thinking so far and would love to hear responses:
TFS 2010 allows linking changesets->work items->builds
TFS 2010 provides greater customisation of workflow than OnTime
TFS 2010 is integrated into the Visual Studio IDE - This requires less apps to be open and less window flicking
Thanks in advance.
TFS is one of the least intuitive Version Control systems I have ever had the misfortune to have to use. It may have numerous "bullet point" advantages over OnTime (and other comparable systems), in terms of raw feature-lists and capabilities, but the key factor is whether it can fit in with your working processes.
My experience with TFS is that you will be required to adapt to the TFS way of working, because adapting TFS to your way of working will be impossible or too difficult to justify.
We recently reviewed a number of possible alternatives to replace a system comprising SVN and a manual bug-tracking system (Excel spreadsheets). On-Time was evaluated but deemed too expensive and complex.
In the end we opted to continue using SVN, but drastically revised (simplified) our repository structures and chose to combine SVN with the FogBugz issue tracking system. The integration between these two systems was fairly rudimentary "out-of-the-box", but required only a little effort on our part to achieve the much closer level of integration we desired. Certainly far LESS effort than my previous experience of a TFS roll-out involved.
Our SVN/FogBugz system is also now integrated with a FinalBuilder build automation suite.
The result is a system that not only fits our working practices perfectly (since we devised the means by which the systems would integrate to achieve that) but which is also infinitely adaptable as our working practices evolve.
I think that it really depends on the size of your team(s), and what you want out of source control.
I used bugzilla in combination with Perforce for a couple of years and found that both were really very good at their own individual things while working in a very small team (2-3 people), but the suffered from a lack of integration between them and from some little idiosyncrasies that took time to get used to.
I recently moved to a new job where TFS is used extensively. There are 4 main teams in this company with 10-12 developers in each, split into further project teams below that level, and it is in this kind of environment that TFS really shines imo. It's biggest advantages in my view are:
1) The integration with Visual Studio - it's not just a case of having less windows open, but it really does speed things up and make your life easier. Things like VS automatically checking out files for you as you work (no issues with accidental checkouts due to lockless editing), being able to synronise local + TFs builds, being able to quickly compare the local version against previous ones..yes you can get 3rd party plugins to integrate but none to this level and with the same stability.
2) The communication features - simple things like integraton with Live Messenger (provided you configure TFS correctly) are great for large teams. We use WLM to communicate accross the office and for collaboration as its just quicker than walking over to someone else every time you need to ask a quick question.
3) Linking builds/changelists to tasks - Yes other SCMs do this but again it's just done in a very nice, integrated fashion..I guess it's nothing special to TFS but personally I like how it tracks this.
4) Ease of merging/lockless editing. I've had experience with some other merge tools and the TFS one works nicely enough, making merging after concurrent editing pretty simple. It's very similar to perforce in this respect, but also with a usually pretty effective auto-merge tool which I use for tiny edits that I know cannot cause any potential issues with edits other developers are working on.
5) Auto building/build management. Working with a couple of large solutions containing 20-30 projects that depend on each other, this is a godsend. We have it set to queue up a build every 20 minutes IF something has changed, and when one has happened its listed in the history log..so easy to see when you need to update your local libraries.
I don't have any experience with configuring it other than build management, but I have heard that this is the worst part of TFS..that its a bit of a pain to get everything running correctly.
So, translating that to a business case..I'd say that if you are a Microsoft software house with large/multiple teams, then the time savings and productivity improvements that you will see as a result of the above features are worth the investment in setting it up. Its free to use in most cases as you will probably have a MSDN subscription (maybe some CAL issues but i'm not sure) so your biggest cost will be in user training and configuration.
Firstly, I would suggest to consider what is your primary concern, what is the problem that you are tying to solve by rolling out TFS.
In terms of version control I would recommend the blog post from Martin Fowler on Version Control Tools and a follow up results of a version control systems survey. Admittedly this might be and is a subjective view of the subject but one that seems to be pretty popular. TFS clearly looses in comparison to other Version Control Systems.
I currently work with TFS2008 and we have migrated from SourceSafe and IBM ClearCase/ClearQuest and there is no doubt that TFS is far better then any of the previous tool, still it has its serious shortcomings and the new version will only partially address those.
Addressing the individual point you have raised:
TFS allows to link builds with changesets and work items, but so many other systems
I have not used OnTime but the workflow customisation can be both an advantage and a hindrance. Potentially, there might be a lot of work involved in creating a custom process template and you would still need a sensible UI on top of it (Team Explorer or Web Access might not be sufficient)
Integration with Visual Studio is an advantage but there are add-ons to Visual Studio that allow integration with other source control providers
On the advantages of TFS I would probably mention
Distributed builds and separate build agents - if you do many builds
Full integration with Visual Studio via the Team Explorer
Extensive reporting infrastructure (though you can only take full advantage of it when using MSTest for all the testing)
SharePoint collaboration site for each project
Given the substantial cost of rolling out full TFS installation I would really consider what real business benefit would this solution give you that others don't.
Not shure about TFS, but the UI of OnTime is kind of non intuitive.
Also I dont like that you have different fields for Bugs and Tasks. Of course you can always add your own fields, but the default layout should be ready to use.
We endet up using only "Bugs" even if it is a task.
I dont say its a bad product, but if TFS has a better UI for bugtracking now (which it hadnt 4years ago when I had to use it and hated it ), then this would be an argument for TFS.
Sorry to hear that you want to get rid of SVN. Thats a hard decision.
I'm not sure about the licensing for the Axios OnTime but if you have an MSDN subscription then it's no additional cost. See the blog post here
I've been using TFS 2008 only for version control and while it's a nice upgrade from VSS some things that we're tyring to do aren't exactly in line with what is expected. That said, I've written a quick little web app that fills in those gaps. It was pretty easy to develop against using the API and there's lots of addons to help with specific tasks.
Probably not the answer you want to hear, but I'd be doing my damnedest to make a business case against TFS.
In any event, my general advice would be to try it out yourself (or in a small team) on some very small, but real project - maybe some tool you need on a once-off basis, code that can be thrown away or easily migrated to another system because it's small. There's nothing like actually using the system!
I have used OnTime and Subversion. I have not used TFS as bug tracker, but I've used it for source control. The source control part of it is basically still the bad old Visual SourceSafe. If you are currently using Subversion you will be swearing your head off any time you need to rename a file or, heaven forbid, delete a file and then create one with the same name - never mind any branching or merging. It's hard to convey in a post just how primitive and fragile it is as a source control system - that's why you really have to use it. You'll see what I mean when you find yourself stuck with a file you can neither check in nor delete and some meaningless error. Not that Subversion is perfect - but it's a decade ahead of VSS!
The workflow part of TFS, which I've only briefly played with, seems very "heavy" to me. That is, it really restricts the user to that workflow and requires a lot of steps that are often unnecessary. This stuff can help, but it can also just as easily get in the way. A good system provides the workflow when it's needed, but allows you to bypass it when it would just get in the way. When we used OnTime, we found that even its relatively unobtrusive workflow was often just more trouble than it was worth. Of course, this all depends on the specifics of your situation. How are you using OnTime workflows now and what do you want out of TFS that OnTime doesn't provide?
Linking changesets to bugs can be done with Subversion as well. It supports some extensibility mechanism - I don't remember the details, but FogBugz uses it (we switched to it after OnTime). Linking the to builds can be done by adding a simple svn tag command to your build script. Visual Studio integration can be done with VisualSVN.
The cost is also a huge downside of TFS. It is very expensive for what it does, especially when you take into account how well it does it. Yes, it's "free" if you have to have an MSDN subscription for every developer anyway - but do you have to, without TFS? Subversion is free, full stop. OnTime and FogBugz are far more reasonably priced.
I would strongly recommend against TFS. I once tried to restore the source code from a crashed instance, but I gave up after a few days, so source code was lost (= it failed to do the one thing a VCS should do). Of course, I might have done something wrong, but it's not easy to get everything right when the restore guide is two miles long, and it really is something that should happen so rarely that nobody is experienced with it.
Now I use Subversion/Trac, which gets the job done (and customizing the workflow in Trac is so easy it's not fun, compared to TFS).
For the time being, avoid TFS!
I would stick with SVN + FinalBuilder and then choose between FogBugz or CounterSoft Gemini.
I finally was able to complete the installation of TFS and started the creation of my first team project which introduced me to the process template.
After following to the link to Microsoft's site for process template information I was inundated with new information to consider. What templates have all of you had experience with that either worked out very well for you or were more of a stumbling block to the project? What were the biggest advantages and disadvantages you've encountered?
Some information about my project, I'm the lead developer for a small company and will be using TFS/VSTS to create an intranet portal to consolidate the end users day to day and increase automation to enhance productivity etc. It's entirely new development taking advantage of C#, ASP.NET and SQL Server 2008.
Ideally I'd like to take advantage of features to enhance collaboration with the stake holders to help add desired features and to track the status of development and offer feedback etc. I was also looking to take advantage of JetBrain's TeamCity for my TFS so if any specific template / software really adds cohesion between TFS, TeamCity, Developers, and Stakeholders that would be ideally what I'm interested in.
Are you already using a software development process like scrum? If yes you can try this Team Process Template over here.
How large is your project team and the project? Microsoft has published one of it's internal Process Templates (MPT) over here. You can get some guidiance and inspiration from this template.
As tangurena mentioned. People use the standard templates, change the bug a bit and store some documents there. I would recommend to keep the process 'light' as well.
However the process template isn't all.
Here are some ideas what I would do (in your case):
Create some high order workitems (features/stories) which stakeholdes can create (constraints and TFS user groups are your friend). They can then access their requested features via the TFS Work Item Web Access. That way you don't need a CAL for them
Create some reports which show planned work accodring to releases.
Setup the build automation and create Reports (a.k.a. Release Notes) from your workitems according to the builds.
What were the biggest advantages and disadvantages you've encountered?
Imho the biggest disadvantage is that you start believing that the template is your silver bullet. It's not, it's your starting point.
The TFS ecosystem offers you alot opportunities to create own bits of software that fit your needs. Just check out the TFS API.
Here is another nice agile-based template (original is on SSW, but you have to get around a login wall).
This template helps enhance cohesion between developers, managers, and other stakeholders by including more robust support for project process (documentation, reviews, &c., &c.). For example, there are types built in for process elements like release plans.
In general terms, I'd favour as small a process as you can manage. The more states, the more fields you have, the more likely the information in them is just plain wrong.
We're running with our own version on the Agile template. Most of what we did to it was delete stuff.
You can use the TFS API to log builds into the database, which should enable you to bridge TeamCity and TFS. Other than that, I'd probably just go with the web interface that comes with TFS, I don't think you need third party software for this.
K.I.S.S.! I created a custom work item based off the Agile one. And thats it, just one work item. There is a "System Severity" that IT uses and a "Business Priority" that the client/customer uses. There is also a "Request Type". With those three along with the built in Area and Iteration the entire team, including the clients can query the work items to get only the items they care about for the release they are concerned with (or all of them regardless of the release).
I did not modify the state machine much at all. This left us with something that is very flexible for everyone. Everything from blue sky requests to the mundane content/visual bugs can be logged there.
The client uses TFS Web Access (unlimited CAL) and the devs (me and 1 other) use VS. At my last job I created the same setup, the dev team was a team of 5 and it worked even better there! I was dev lead there as well and technical PM.
The biggest advantage was having a very flexible system for everyone, when using 1 work item type for everything. The disadvantage would be a learning curve for the client, but once they knew how to use it most like it. A suggestion would be to look into cheaper tools out there for a similar implementation, but, our .edu discount with MS cant be beat.
I would have to say that you must identify the system you will use for your company's SDLC first. The process template is merely a tool and without a good understanding of the underlying process it will not help and can make things more difficult. User adoption is crucial to the success of the SDLC and process template.
We use Scrum for Team System. We chose this due to our experience with Scrum as an SDLC methodology. There are several excellent books and articles on the web to help you get up to speed. Scrum will tie together the business stakeholders into the process.
In our system the Product Manager is in total charge of Product Backlog Items and works with myself and the CTO to prioritize them into Sprint Backlog Items.
The only change we have made to the process template was to add a "Failed Test" state and corresponding workflow.
It might not be the best template for you but I still wanted to mention it here: XP for Team System. It is basically a simplified version of MSF for Agile Software Development:
[...] it removes some of the setup tasks that an XP project will probably not want to undertake and changes the Work Item Type name Scenario to Story.