I am working for a company now for a couple of weeks. The build process is done mostly manually and takes several hours spread over several days. The languages in use are C#, COBOL, Delphi, Visual Basic 6, and of course the database with T-SQL. For the version control, we use Apache Subversion (SVN), except for COBOL code and the documentation, which is kept in Microsoft Visual SourceSafe (VSS). I have the idea to improve the process using a continuous delivery tool. Do you think that Jenkins would do the job?
Thank you for your reply.
Jenkins is undoubtedly a tool that can help with CI/CD.
Whether it is the right tool for your particular needs you should be able to determine by doing your own research into the capabilities of Jenkins and the tooling that it supports. You may find that you struggle with finding adequate support for the older technologies that you mention and you will likely find that you need to uplift some of that legacy to make it usefully available to any viable, modern CI/CD tool.
e.g. get your code out of SourceSafe. You should do that anyway because .. SourceSafe. :)
Don't get bogged down in how to migrate your history. Just shutter SourceSafe (make it read-only) to retain as a reference to your history and move tip/head into a new repo. (SVN if you have to, though I'd highly recommend Git).
More generally, I would be surprised if you could not find some immediate quick-win improvements that can be made, without needing to invest time/effort/money into a "Silver Bullet" tool, just by putting some scripting in place to automate current manual processes.
Jenkins is definitely the right tool. We use Jenkins as a CI tool for building our Delphi (+Dunit+Innosetup), C# and Cordova/PhoneGap applications (all code in SVN).
I have no idea of the dependencies between the code in SVN of VSS, but if it depends on each other, I would advise to put all the code in a SVN or GIT repository.
There are some simple examples to integrate Delphi in Jenkins, see the following links:
https://community.embarcadero.com/blogs/entry/continuous-integration-with-svn-jenkins-and-dunit-delphi-with-craig-chapman
http://www.ictexpertise.com/blog/2016/02/10/continuous-integration-of-delphi-project-with-jenkins/
http://chapmanworld.com/2015/01/18/use-radstudio-with-jenkins-no-plugin/
Two questions really..
Does anyone know of a cheap solution for converting a CVS repository to TFS?
I think we may have to convert to SVN then convert to TFS. Has anyone had experience doing so?
Please, no comments on why we are using TFS.
The TFS Integration Platform on Codeplex is written to support integration into and out of TFS. Though it is primarily written for a TFS to TFS scenario, the code is available for you to tweak as necessary.
A few years ago, we used the original version of this (called the TFS to TFS Migration Tool) to facilitate our migration from Borland StarTeam to TFS. It worked really well.
The key thing you're going to need to decide is whether or not you want to bring over history. That's where things can get a bit more difficult, as you will need to rebuild the history from the beginning of the CVS repository. This means reading the first revision of all the files, checking them into TFS with appropriate comments, then getting the second changeset, checking in those files, ad infinitum.
We are a mostly MS shop at work doing .NET LOB development. We also use MS Dynamics for our CRM app... all the devs are currently using VS/SQL Server 2008. We also use VSS, but everyone hates it at work and that is quickly on its way out.
We are begining our initiative for TDD implementation across the team (~dozen ppl). I've gotten TeamCity setup and have my first automated builds running succesfully using the 2008 sln builder and also using SVN that a co-worker had setup who is doing the source control analysis. When demoing to managament, I think they started to buy into my snake oil and threw out the suggestions of looking into TFS.
This threw a wrench in what I had planned for our TDD architecture; In a good way though, because I had always assumed that TFS was just too expensive and not worth it for our team (and i've seen the same in other shops i've worked at / know of). I do feel like MS is years behind in the TDD/CI area and that the third party products were probably much better and more mature... I still need to do a lot of research, but I figured I'd come here to see if anyone has actually used both systems.
I realize the TFS encompasses a lot more then just a build server... but I didn't want to make this too broad of a question at least on purpose. What are the practical pros/cons of using TFS/TFB instead of TeamCity - e.g. which benefits would we lose/gain? Has anyone here actually used both systems (TFS for TDD/CI and TeamCity/SVN) and can speak from practical standpoint?
I've done some searching on this topic, and one post I found here on SO mentioned that the cons of TFB was it only supported MSBuild. I was planning on using FinalBuilder with TeamCity; and it appears it also supports TFS as well...
Thanks for any advice
EDIT: Has anyone used TFS as their Build/CI server and can tell of success/failure stories?
We are a small development shop, and decided that Team Foundation Server carries too much overhead for us. We used to write custom MSBuild scripts to run from the command line, but after we discovered TeamCity, we moved our entire build process over to it.
We've found TeamCity to be easy to use and configure, and JetBrains provides excellent support and documentation. They are also on a much faster release and update cycle than Microsoft.
Their support for SVN source control is excellent, and we like the fact that they support both MSTest and NUnit for unit testing.
We also liked the fact that the TeamCity Professional edition was free, so we could evaluate it to see if it worked for us. We haven't hit the number of project configurations (20) that would require us to upgrade to the Enterprise edition.
This question has a lot of good answers about TeamCity. It does not compare to TFS but it might shed some light on TeamCity for you.
I have used both, and I have had success with both, but TeamCity was so much easier. TeamCity was a breeze to set up and configure. TFS was not. TeamCity is rock solid, it's easy to maintain and it just plain works. The developers at JetBrains have done a great job responding to the community. They get a release out every 6 to 8 months that adds real value. TFS is on a 2 year or more cycle.
TeamCity gives you more choice in how you build and what source control you use. It's not all in one, but that's sometimes a good thing. It's got a good set of extension points as well. We have also been really happy with the agent model it has.
I've gone through 3 absolutely painles upgrades in TeamCity. The one TFS upgrade we did took our build and source control down for 3 days. I'm the admin for TeamCity on our project and it takes up a couple of hours a month. TFS took a couple of days a week.
TeamCity + SVN + VisualSVN has been the smoothest environment I have ever worked in. TFS was generally smooth on the day to day, but only if someone was there keeping it running.
Hope that helps
The benefits of TFS are one integrated environment that is supported by Microsoft. I personally do not like TFS for source control and have had a number of issues with it. It is clunky, however it had the benefit of having VS integration (which is also available in VisualSVN, but is not as robust).
Personally, I think you would be much better off using SVN/TeamCity. It is just easier to work with and behaves more as you would expect. As with most open source software, both are constantly evolving and will always have the latest and greatest feature before Microsoft. The integration between the 2 is really good and I have found no fatal flaws in the system. I constantly push to go this route in my current company (we use TFS), as I believe it is a much better workflow. As an added benefit, it is significantly cheaper than going the TFS route.
I have also used FinalBuilder with TFS - my question there is what are you really buying with FinalBuilder that you can't do with NANT/MSBuild? The answer at my shop is unfortunately very little IMO.
First off, see this post:
SVN vs. Team Foundation Server
As to your question about which environment better fosters TDD and such, my two cents is that the build management system matters much less than what's in the build file itself. Your Ant or MSBuild file should have the targets that do your testing. With MSBuild or Ant, you don't have to use MS's test suite. You can still use nUnit or whatever else you want. That means it doesn't matter if TFS is calling your MSBuild file, or if CruiseControl is, or if TeamCity is. The smarts are all in the build file and the tools you integrate with it.
My personal choice is not to get locked down into TFS's way of doing things, since you have a lot more freedom for a lot less cost with the wealth open-source testing tools that are out there. TFS is about to receive a major upgrade, as well. If you are going to go with TFS, my advice is to at least wait until 2010 is released. Concentrate on making your MSBuild files as good as they can be right now.
That being said, I must admit that TFS has one of the nicest build systems out there (2005 was terrible, 2008 was nice). Being able to easily customize notifications and the release process all inside .NET code was pretty cool -- you had a lot more central control over build and release policy than we did with CruiseControl.NET.
So I've used TFS and SVN/CCNet. I can't speak much to TeamCity. But IMO a build management system should be fairly agnostic to what is being built and how it's being built. For us, the extra control in the release management process that TFS brought us just wasn't enough of a bonus for us to justify the greatly increased administrative effort of a fully integrated TFS solution. Nor was it enough to justify the extra per-license cost of TFS, which can be significant.
The old TFS Build was XAML based and very cumbersome and and not nice to work with. That said, the new TFS 2015 build system is leaps and bounds better, and is script based with lots of web hooks and 3rd party integrations; very similar to Team City. Also, TFS now supports Git, so you are no longer confined to using Team Foundation Version Control (TFVC). Also, with TFS you can use your own on-prem installation, or can take advantage of a hosted solution through visualstudio.com. TFS is great because it's one completely integrated environment (work items, planning, builds, tests, deployments), whereas Team City is just a build solution. When this question was originally asked in 2010 I would've recommended Team City hands down. Now though, the 2 are very competitive. I would say that it would maybe boil down to if you want an all-in-one solution, then go with TFS, but if you are looking for purely just a build system, then Team City.
Comparing TeamCity to Visual Studio Team Services (the latest cloud-based offering from Microsoft):
Both work great for implementing a continuous integration process
TeamCity is more mature and everything just works.
Visual Studio Team Services by contrast is constantly evolving to catch up with TeamCity and some things just don't work well (e.g. try triggering builds based on paths that have changes from Git - the documentation is weak and the feature itself just doesn't work (as of August 2016))
Visual Studio Team Services makes it easy to have only cloud-based agents running your build (the downside however is that each has to do a clean pull of your repository for each build which may add a minute or more to the build). Both can also support local build agents which do not need to wipe the working directory for each fresh build.
But in either case I would highly recommend you also look at CakeBuild which moves most of the configuration information about how to do a build out of the CI system and into C# code that is in your Git repository along with all your other source code. With CakeBuild you can run the same build locally as you will run in the CI system and if you need to go back a month to build a specific version you have the source code and the build script to do it.
With CakeBuild in place you are now free to easily switch between TeamCity and Visual Studio Team Services.
The only downside to CakeBuild is that all your build steps are bundled into a single task in the CI system which makes reporting slightly less nice and may involve some extra work to get the test results out into a format that the CI reporting system can use.
MS is years behind in the TDD/CI area
Being one who has TDD'd for 4 years now you are correct. MS is still not even promoting it nor do they offer tools that work well with the TDD flow.
Don't get stuck dealing with Visual Studio for any kind of automation, source control, or agile workflow period (stop using TFS please!!). That stuff even though they say is "new" is monolithic and always comes with weird issues and bloat. It is always painful.
I've used Team City and it's simply amazing, things work, it's designed for usability, and it's simply designed well and compatible with most all test tools, etc. Fine use Visual Studio for code, nothing else. Look for external and open source tools to help build a better CI. The "you can do everything right in VS" sell is not selling, and it's not working. People nowdays are used to and always combining different tools from the outside to get things done. Relying on all MS toolsets is just not the way to go IMO for .NET. MS likes to sell "hey you can just do everything right here". But you end up with nothing but pain when you go that route and drink their koolade (TFS, MS Fakes, etc.).
If you plan on doing TDD, you definitely don't want to be using all MS tools. You'll either be pushed down "their way" of doing things which is often proprietary and/or bloated when you try to TDD with their tools or be totally restrictive. For TDD you need to be able to have some flexibility and choices when you decide to layer in different test frameworks, assertion libraries, etc.
Add Octopus on top of Team City, and it's stellar...you will simply fall in love with it as developer or for anyone doing DevOps.
Stop trying to rely on Microsofts continued failure at agile tool offerings
Start looking outside the box and try new things is what I keep repeating to the .NET world, me being a .NET developer in the past and who has tried new things outside the MS world.
Currently our build solution is set up using TFS + MS Build scripts.
TFS is also being used as a CI server.
I've seen several posts on this site telling people about other CI solutions.
Are there any compelling options to move to another Solution for our build system?
Or in other words what are we missing out on by using TFS?
EDIT
We are using TFS for source control / issue tracking and I think this is a good solution, im just wondering about the other options for build server / CI server integrating with TFS.
The main problem with TFS is that if you have a server crash, restoring your source code is non-trivial. This is unbelievably bad since the most important aspect of any source control system must be to be fail-resistent, at least if you perform all backups as you should.
IMHO the greatest benefit of TFS is that everything is integrated in the IDE: work items, bug tracking, CI, Code analysis, ...
I have used TFS in the past but my current company use SubVersion/Team City/FogBugz to implement the same functionality provided in the TFS solution.
I would say that from a technical implementation perspective, you can gain additional features from a non-TFS system that TFS would be a nightmare to configure.
However, that said, one of the biggest reasons for not going for TFS is the cost of running such a system. The big advantage of TFS is the integration of everything which makes people use it more as the more you put in, the more you get out. The worst case scenario is a system that people can’t be bothered using which adds no value to the company’s development.
In my opinion, if you are already on TFS and can afford to stick with do, do just that!
We are just about to implement full blown TFS 2008 across our development team and I'd like to find out if there are any gotchas to b e aware fo or any installation issues I am likley to face. I have Googled all the obvious places and read the anti-panic blurb on the MS sites.
Currently we have ClearQuest, SourceSafe and Final Builder. It's my understanding that all of these can go once we implement TFS. If that's true it sounds pretty good already!
One problem I had was in setting security. I needed to lock down a branch to read-only for almost everyone. So I removed all the existing entries and then accidentally hit OK. This meant no-one -- including server and project admins -- had any access. Including no one having the rights to fix it.
Turns out there is a work around, and knowing the server admins helped. A local administrator on the TFS data tier server bypasses the TFS security, and could reset the permissions.
Did cause a few minutes of panic...
We have some slight problems when checking in with the Visual Studio integration, it happens quite rarely but can be somewhat annoying. The VS plugin seems to think it's checked in stuff, but it really hasn't. Usually it can be resolved by checking out everything then checking it in again, and you can do it with the Explorer plugin as well if you need to be really sure it works.
We don't use the bug tracking and Wiki features in TFS, but rather JIRA and Confluence, as the functionality TFS provided didn't quite suit us.