Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I am looking for a free alternative to TFS. What would be the best alternative stack(source control, bug tracking, project management/planning, wiki, automated builds (ci))? Keeping in mind that it would be nice if they all integrated well.
For example, it would be nice to be able to link bugs to source control, and then be able to link to a project plan and then be able to automate building.
I do not have issues with using Microsoft project to manage project planing.
I know i would like to use these....:
SVN
TeamCity
NUnit
But i am struggling to find a good Wiki/Project Planning/Bug tracking, that would integrate well.
Any questions let me know.
Bug tracking / project management / planning
JIRA (not free but $10 for 10 users)
There are various modules to add to this. I use GreenHopper which is an agile process addon. YMMV. If you like gant chart planning, there is a MS Project pluggin (I've not used it)
Also checkout YouTrack. This integrates with TeamCity as a bug tracking tool. It's quite cheap, but I didn't get on with it in the beta. YMMV.
There are loads bug tracking systems. This will be where you spend most of your time so I would select one that suits the way you work, rather than one that integrates with your source control (unless you have a very strong requirement for change control/auditability)
CI / automated build
All CI servers will integrate with your source control. I would hazard a guess that all CI servers can be made to work with all source control systems so in this sense they are all integrated.
I used TeamCity for a while which is awsome. I stopped because I hit the 20 projects limit, and we couldn't afford to upgrade :( I would recommend starting with TeamCity as it is very easy to setup. Its actually quite easy to change your CI server as long as you keep the actual build in a script.
Also available is Hudson. This is free. There are addons to integrate with SVN + JIRA (in fact the addon scene in Hudson is a real strength). This means that commits to SVN containing links to issues generates a html link between the hudson build/ jira issue / svn commit making it easier to match code changes to features. Hudson works, but to me it seems like a beta product. This could change rapidly but I don't have the confidence in it that I had in TeamCity. However, I shouldn't complain because it's free and I haven't even contributed a bug report :)
The other main CI server is CruiseControl which I've not used.
Build scripts
Nant / msbuild / rake / others. I use msbuild which with a bit of head scratching can be made to do the business. I've not used to others.
Test frameworks
In .Net land I would guess that NUnit is probably the best supported and most widely known. There are others, especially those that encourage BDD.
Wikis
Not sure what you are after here (I've not used TFS) There are loads of free wiki engines to choose from. Full disclosure, I've not used any!
Best I could come up with.
SVN (Source Control)
Team City (Continuous Integration)
NUnit
Trac (Project Management/Bug Tracking/Wiki)
Its funny though as a result you now have to install Java (Team City) and python (Trac), to get your free alternative.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm trying to get myself updated on workflow/deployment automation tools but the quantity is overwhelming and I cannot discern the differences of purposes of the multiple tools I'm finding.
So far the ones that I found interesting are:
Magallanes:
What I understood so far: It's a deployment tool. Its purpose is to automatize deployment so you can get rid of most human errors and time to do the deployment.
Travis:
What I understood so far: Continuous integration tool. It's used to automatize test integration on commit/deployment. But... can It automatize de deployment as well? Should I integrate it with Magallanes so Travis can manage the deployment with Magallanes?
Jenkins:
What I understood so far: Same as Travis but not as a service but as a tool you can configure and install instead. Same doubts, can I automatize deployments? just test integrations?
Ansible:
What I understood so far: Automatization of multiple tasks, deployment, sevice configuration management... I guess I can get rid of Magallanes and use Ansible, is this right? Can I integrate Ansible with Travis? or does travis also the Ansible deployment work (is the only automation I am interested at the moment)?
As you can see I'm lost here.
Wow: Already a close vote, where should I put this? It's a programming related question, they're programming related tools.
Edit: The thing is that I need to implement a deployment tool with the team and the projects I'm working on.
The doubts I do have are about, which tool should I be using (or which tools should I be integrate together). For example: I know Travis is for Test automation, but Can I use it for deployment? As I said, should I use it together with a more deployment oriented tool (Magallanes, or Ansible)... Maybe directly with Git?
The team was using Filezilla to upload things to production and SVN as a code sharing tool (no branches)... I was thinking of usin Git (server side, bye bye Filezilla) with hooks and a fine branch system but I know there're better ways and more complete deployment flows.
Travis and Jenkins are both continuous integration tools. Their primary purpose is to run your test suite on all commits, but some tools in this category can also trigger automatic deployments when the build is passing. People writing code that needs to be compiled will sometimes talk about build artifacts, which are the things that can actually be deployed, but if you're using PHP, you're probably just doing a git pull or dropping a tarball on the server, so you don't need to be concerned with this aspect of CI tools.
I haven't heard of Magallanes before now, but yes, it appears to be a deployment tool. Many companies create their own deploy tools for their specific situation, sometimes based on a tool like Capistrano or Fabric.
Ansible is a configuration management tool. Primarily this is for managing configuration of your servers, but as a side benefit, since it knows about all your servers, it can also handle deploying new code to them. Other popular tools in this category are Puppet, Chef, and Salt.
These tools are all about automation of pre-existing processes. So, as you find a step that you're doing over and over again, go research what tool can be used to solve that problem; I find this to be a much better approach than to find the tools first and try to determine what problem of yours they can solve.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
We are transitioning across to BDD. Currently using specflow and visual studio to run our automated tests via Jenkins and have over 1000 tests in Quality Centre written in a more traditional fashion of which, the regression tests will be converted to BDD in time.
I'm looking for a repository (similar to test plan in Quality Centre) to house all our test cases/feature files. It must be compatible with Specflow and Jira. What do people use as a manageable test case repository for their tests?
Cheers.
I'm not 100% sure I understand your issue, not being familiar with some of the tools you talk about, but when you have executable specifications your test cases are in the feature files which are stored in the code base. This is part of the point, that your test cases are the things that get executed, so they are always up to date.
What #Sam-Holder said is good; adding to that because I'm familiar with the issue and the tools you're talking about.
You're probably used to the idea that Quality Centre contains a bunch of test scripts, some of which pass and some of which don't (yet).
When you're doing BDD with automated scenarios, they pretty much always pass, all the time. Half the things that QC does simply aren't needed with modern Agile processes.
A pretty common practice is to put the scenarios into the Jira story until they're automated. They're transient. Nobody ever looks at Jira once the story's done. The codebase is the single repository of truth, and anything that lives in Jira gets ignored.
The automated scenarios are checked into the same codebase as the code. If the scenarios go red (fail), the team makes them green ASAP. They provide living documentation for the code. See if you can find someone to show you what Jenkins looks like in action and you'll get a better picture. Commonly the Jira number is added to the check-in comment to provide some level of traceability.
I think it's good practice to keep any manual test cases checked in alongside the automated ones (though please do question why they're not automated; if you automated them in QC you can usually do it with SpecFlow). This helps the test cases (scenarios) to provide living documentation for the code. In fact, getting rid of the word "test" was part of the reason why BDD came about, because BDD's really about analysis and exploration through conversation. It provides tests as a nice by-product.
To answer the question, the most commonly used tool at the moment is Git (at least for newcomers). It's version control that the devs are using. SVN / Mercurial are also OK flavours of version control. Get the devs to help you.
If you're still working in a silo and not talking to the devs, don't use BDD tools like SpecFlow - you'll find them harder to keep up-to-date, because your steps will probably be too detailed and English is trickier to refactor than code.
Better still, use the BDD tools and go talk to the devs and the BAs / SMEs / Product Owner who understands the problem. Get them to help you write the scenarios. When you start having the conversations, even over legacy code, you'll start understanding why BDD works.
Here's a blog post I wrote on using BDD with legacy systems that might also be helpful to you. Here's a blog post on the BDD lifecycle: exploration, specification and test by example. And here's one to get you started on how to derive that "Given, When, Then" syntax using real conversations.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We have used TFS2012 on the cloud and we don't like that there's no reporting service so we're looking to move to on-premise TFS2012. At the same time, we're starting to like Git and we're thinking that it may make more sense than TFS version control.
This obviously requires research and developers to "play admin" so we're taking the time to evaluate whether Jetbrains' highly-appraised solutions are a better fit.
Given a team of 6-8 people that run with Scrum that is eager to be on the "best practice" train for agile and a project that combines .NET technologies for the back-end and Javascript (AngularJS) on the front-end, considering a move from TFS2012 to a TeamCity/YouTrack/Git stack for scrum planning, source control, continuous integration and quality control and issue tracking:
What would/could we miss from TFS2012?
What are we going to enjoy from the new stack?
Is the new stack falling short in any respect that TFS is not and vice versa?
Note: This is a question specific to TFS2012 - there are several comparisons on SO and elsewhere for previous TFS versions and TeamCity, perhaps YouTrack too.
Here's a brief account of my two-week long experience with Git/YouTrack vs 6 months of TFS.
The new stack feels a lot more lightweight than TFS. Both installing (we tried the on-premise TFS shortly) and using TFS gives the sense of a very heavyweight enterprise suite for no reason. This is partially an illusion that the UI design gives but it seems that with YouTrack:
Takes less clicks to do anything and even less if you learn some shortcuts and how to use the commands.
It's easier to navigate between the views - there are less of them but give a better overview than TFS. This is not because they present more info - in most cases they present less info - but because they give the key information in a visually clean way.
The ability to run ad-hoc searches in YouTrack makes such a big difference! In TFS you have to create a query with a UI that tries to makes it easier but ends up making it harder for you than just typing the query params. I mean, we are developers after all.
I've enjoyed the local commits of Git and how pull requests work to integrate work from other people into a main branch vs merging on TFS.
TeamCity has also been very lightweight to use - though I have no experience with CI on TFS. Having said that, it's an area I didn't delve into much because I was already spending a lot of time managing TFS.
Hiccups and things that I miss from TFS:
It's a little harder to manage releases with YouTrack or I haven't figured out how to do it effectively. The management and separation of product backlog, release backlog and sprint backlog is easier on TFS.
There's no way to plan a sprint based on capacity of developers - I believe JetBrains is working on that though.
You gotta pay for a private Git - though YouTrack/TeamCity are free and full-featured for a few users.
I'll try and keep this up to date as I go.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are the issues we may face if we move from TFS to Fogbugz Kiln?
currently we are using TFS for source control, we are looking at the option to move to Kiln.
we are completely Microsoft development tools based company since we use Visual Studio .net, SQL server, TFS, Windows servers etc..
the reason for move it seems are:
better code review tools in kiln
better branch merge management.
has anyone already done this? does anyone know issues when we use visual studio with Kiln?
I cannot answer your question completely, as I don't use (and have never used) TFS. However, my employer uses StarTeam which is pretty typical as far as source code control.
For me moving from a traditional SCC method of check out/check in, to a distributed model was the first mental hurdle. To get over that hurdle I found that the tutorial at http://hginit.com/ was helpful.
As far as using Kiln for with VS, I use both the Kiln client (essentially TortoiseHg) and a plugin for VS 2010. I can commit, pull, push, etc. from both the Windows Explorer and from Visual Studio. I have had no issues, other than learning mercurial and how distributed version control works.
As far as other issues, the only ones I can think of are updating any build server or continuous integration servers to pull from the appropriate repositories.
Codereview exist in TFS (just download a free extension), merge is very good in TFS, reports are better in TFS, methodologies, integration, and even price.
In my modest point of view. But both are great products, if you work or need distributed sc or mixed teams (linux, etc) also TFS has a solution, but is not so cheap
Branches are better in Mercurial, but this has a price: you're going to have much more branches, and it will be much easier for a developer to make a mistake and do something in a wrong branch. Flexibility may cause confusion.
But the most important thing is your transition plan. If you have a long commit record in TFS, you'd probably want to keep it. Unfortunately, there seemed to be no direct conversion tool to help converting TFS to Hg when I needed one. I tried using tfs2svn with hg convert, but tfs2svn got stuck with complex renames, and I was forced to write a dumb direct conversion utility instead.
We switched from Sourcegear's Vault (w/ Bugzilla) to Kiln (w/ FogBugz) last Fall. All of our developers love the tight integration of commits to code reviews to cases (bugs/tickets) to specs/requirements.
It took some trial and error to master the organization of the central repositories. Kiln (and Mercurial by proxy) is so flexible that you can easily construct an organizational structure that is either too simple or too complex. This is significantly mitigated by the ease with which you can branch and merge. Our goal was to construct a system which allowed only reviewed code into a staging repository which could then be deployed for release to QA. It took about 6 weeks (mostly to trial and error) to finalize our repository organization to streamline this process.
While in Vault (comparable to Subversion from a philosophical standpoint), you could easily commit a change which could cost hours of time reversing, in Kiln it is trivial to make changes and throw them away. While I can't speak for TFS, compiling for release in Vault was a nightmare. Take 90 minutes of productivity and trash it. In Kiln, it's trivial to write a few Perl scripts to automate build/release, which would now be almost instantaneous if not for a few minutes of manual review.
The biggest challenge (as Helgi suggests) is managing branches. Some developers find this extremely easy, others struggle with it.
There was no conversion path from Vault to Kiln either, so we maintain the Vault server instance for archive purposes and started fresh with Kiln.
6 months in, and it has changed our lives (for the better).
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.