Can someone tell me please if is a good idea to use TFS as ticket manager for end users and in the same time as backlog for team developpers?
Not totally sure which kind of ticket manage system you are referring. For tickets, if you mean the ones raised by the end users of an organization whenever they encounter an event that interrupts their workflow.
Then seems you are looking for a helpdesk ticketing system, acts as a documentation of a particular problem, its current status, and other associated information. These tickets are routed to a ticketing software where they are categorized, prioritized, and assigned to different agents according to the organizational norms.
The agents then analyze these tickets and suggest appropriate fixes or workarounds and resolve the issue. As a central repository of all these tickets, an IT Ticketing Software helps in providing the context of the issue history and its resolution.
Then to be honest, this is not what TFS should do. You may have to look for some other system to handle this.
TFS provides integrated tools to support collaborative software development, including Git repositories, continuous integration and continuous deployment (CI/CD), and interactive Kanban boards.
You could also collect bug/feature request and related info from end users, then track them in TFS.
But it's not suggest to let them directly access your TFS system and fire work items by themselves. Cause you need to assign them license and corresponding permission.
TFS fully supports bug tracking and traceability though the code that was changes.
Create your product backlog
The out of the box bug work item is specifically designed to work with the test tools and the planning tools. Besides, you could also use them and add a few customization to meet your requirements.
If you want to use the TFS for the ticketing system. you need create task as a bug /Task in the child link for that particular backlog item or feature. Each task / Bug has to be tracked based on the sprint.
I have two Jira instances (both are Jira Cloud) and the same project in both.
Historically one Jira is used by dev team and second Jira is used by ops.
However, some dev tasks have to be considered by ops team.
So the question: is it possible to sync issues from one Jira to other Jira?
Yes, it is possible to sync issues from one Jira to another, however, this will require you to install additional add-ons to your Jira instances.
In the marketplace you have several available solutions:
Backbone Issue Sync for Jira
Exalate Jira Issue Sync & more
Issue SYNC - Synchronization for Jira
You can trial all of them and pick one that suits you the most. Or in extreme case, if you have some programming skills you could develop such add-on yourself, however, if you include maintenance and hosting costs it's probably cheaper to buys an existing solution.
I'm sure you are aware that you don't have that much flexibility in Cloud. However, check if Backbone Issue Sync plugin can help you or not. In Server it's possible to do it via Issue Sync Plugin.
We are on TFS 2012 currently and planning to upgrade to TFS 2013 soon. I'm trying to better understand what is the best setup for TFS. We currently have multiple teams in the company using it and it is critical as a source control and ALM tool. Nope Visual Studio Online is not an option for us.
Let me know what you guys think specially if someone else has a similar setup.
1) Whether we should have a DR environment for TFS so that if something goes wrong with the Main TFS we can failover? I know we can restore it from the DB backups but that is time consuming specially if the TFS application tier goes down and has to be rebuilt.
2) Should we have a QA/Dev environment so that it can be used to try the upgrade first and if it looks good then done in Prod? It can be used in future to try out features etc. as well.
In a recent environment I was working in, we had a "QA" TFS server that we could test updates\template changes\plugins, etc. That worked out great for the whole team and I would definitely recommend having a test server if that's an option for you.
I can't recommend what you do for disaster recovery as there are many factors involved that your team needs to decide on. My last team didn't maintain a completely separate rollover environment, but there were nightly snapshots of our TFS servers that were virtualized. We could restore from those snapshots fairly easily. That recovery plan was sufficient for this team based on risk\resources\potential downtime.
I hope that helps.
The ALM Rangers publish a TFS Planning Guide which has a section on how to approach DR with TFS: http://vsarplanningguide.codeplex.com/
You probably should also consider designing a High Availability (HA) TFS deployment. Details of how to do this are in the TFS Installation Guide: http://www.microsoft.com/en-us/download/details.aspx?id=29035
In general though, at the core of TFS is a SQL Server, and all the best practices around HA SQL and DR for SQL apply here. Reconstructing an AT is relatively straightforward, and if you design a HA TFS deployment you will have multiple load-balanced AT's so if one fails the traffic just routes to the healthy AT(s).
I currently work in a company that uses FogBugz for issue and bug tracking and SourceGear Vault for source control.
We are now introducing Team Foundation Server. Clearly TFS will replace Vault for source control. My question is, with the following requirements:
Large existing base of FogBugz cases (some obviously open) that we need to support ongoing
Support desk needs to be able to raise bugs / support calls
Want changes to source to be linked to a case number
... what is the best split between using FogBugz cases and TFS WorkItems?
Is it possible to totally migrate from FogBugz to TFS?
If it is not possible to migrate from FogBugz to TFS then what is the best way to use the FogBugz case and TFS workitems together?
Initially I'd say bugs and defects stay in FogBugz, stuff on the project plan as work items. You could manually get the developers to create a work item for each case in FogBugz and associate the code with that work item but I can hear the howls of derision already :-)
You might want to take a look at the TFS Integration platform. I don't know if there are any tools that link directly to FogBugz but these tools are highly extensible. You could then decide to either migrate everything in to TFS or run both systems and synchronise. Running both is nice as each discipline can use the tool they are most familiar with, devs use TFS for everything and the testers / support can continue to use Fogbugz and the toolkit keeps everything in step.
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.