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 9 years ago.
We are evaluating CI environments, there are a number out there:
TeamCity, Go, CCnet, BuildForge, TeamBuild, FinalBuilder Pro, Visual Studio Team System.
I'm having the most difficulty evaluating CCnet vs. Go
What are the pros/cons of each against one another?
Lucas,
First, the word of warning - I work for a vendor in this space (Urbancode - the AnthillPro guys). [/disclaimer]
I think it depends on what you're really trying to get out of the tool and it's hard to guess based on your selected tools. You have free tools, cheap tools, moderate tools, and expensive ones in your list. If you're looking to create a build infrastructure for a big enterprise, the expensive guys are more appropriate whereas if you're setting up just a team level system, open source may be fine.
Aside from scalability, perhaps the biggest difference between tools like Go (and AnthillPro for the matter) and CC.Net is what you're looking to do with them when the build is done. If after the build, all you do is send an email, a basic, team level CI system can be a good fit. If instead, you want to deploy it to one test environment, either system may suffice. If you want to deploy a build through six test environments, get some approvals, and then deploy to production with full audit trails the whole way through, something like CC.Net just isn't going to cut it. You're looking at the Go's, BuildForges, and Anthill's of the world.
Things like integrations are a big deal as well - the tool has to work with the other tools you use.
Eric's answer is very interesting.
In our company, we use CC.net for CI and Deployment. BUT, cc.net is just a tool to manage every other tool that is used in our builds (mostly msbuild but also sql deployments, nunit, iis management...). Thus, we can't say that cc.net takes care of the deployment tasks, it just launch a msbuild script that does the job and aggregate logs to the user-friendly dashboard.
I would add that if you look for a global CI tool (CI + build scripts + deployments) you can forget about cc.net. But if you have knowledge in msbuild, NAnt or any build/scripting language you can use it. The latter's advantage is that your build are reusable, if you change your CI tool you can still use them, if you do a TFS build script, I'm not sure whether you can use it with another tool...
Things we do with CC.net + MsBuild :
basic builds
nightly builds
windows service deployments
huge website deployments
As for Go, I never tried it, sorry. You can think about Hudson (even for .Net) too.
Related
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 9 years ago.
I am looking for recommendations on tools for automatic deployment of Windows Service to several machines. The tool should be able to:
- Stop/Start service
- Copy files
- Modify configuration files on each destination server according to some CSV/Excel file
Advantages: Web interface, notification via email, compression/decompression
Here are the tools I heard of, and I am starting to evaluate, but I would like to hear from people who actually applied one of these (or some other tools) in their automatic deployment process.
Chef http://wiki.opscode.com/display/chef/Home
ayehu AKA eyeShare http://www.ayehu.com/
Puppet http://puppetlabs.com/
Nolio http://www.noliosoft.com/
Octopus Deploy http://octopusdeploy.com/
Kwatee http://www.kwatee.net/
P.S. There is a similar question on SO, but it does not answer my question:
WCF service deployment - tools
Answering
Q: How many servers do you plan to deploy to?
A: Currently 20 servers in 2 data centers. The numbers might grow in the future
Q: How many users will be involved in designing and executing the deployment?
A: One would design the deployment, and somebody else (a single person) will execute it
Q: Does your deployment require Cross-tier synchronization?
A: I need to deploy only a single Windows Service, no database changes, no IIS or any other web tier
Q: How important are auditing and reports to you?
A: I would like the tool to be able to report whether its succeeded or not. It would be also nice to see a complete dashboard of all the deployed servers with their versions and recent changes.
You can try Jenkins (http://jenkins-ci.org/)
This tool provides a nice UI to configure automatic build and deploy any project. Also it have rich set of plugins available on internet.
You could add kwatee to your list. It's lightweight with a web interface for configuration and CLI tools to automate the deployment process. You can handle your target-specific parameter with built-in deployment variables but there might also be a way for you to do your own parsing of CSV files and inject them. Note that you must enable either ssh or telnet/ftp on your target computers.
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 11 years ago.
It took me an hour or so to work out Hudson has only branched recently (Jan/2011)
I have no idea how rapid the change of each branch is now, but more importantly, what is the direction each branch is taking and what are key points so one could make a choice between which to go with?
Anybody have links to product roadmap and feature differences?
Use Jenkins.
Jenkins is the recent fork by the core developers of Hudson. To understand why, you need to know the history of the project. It was originally open source and supported by Sun. Like much of what Sun did, it was fairly open, but there was a bit of benign neglect. The source, trackers, website, etc. were hosted by Sun on their relatively closed java.net platform.
Then Oracle bought Sun. For various reasons Oracle has not been shy about leveraging what it perceives as its assets. Those include some control over the logistic platform of Hudson, and particularly control over the Hudson name. Many users and contributors weren't comfortable with that and decided to leave.
So it comes down to what Hudson vs Jenkins offers. Both Oracle's Hudson and Jenkins have the code. Hudson has Oracle and Sonatype's corporate support and the brand. Jenkins has most of the core developers, the community, and (so far) much more actual work.
Read that post I linked up top, then read the rest of these in chronological order. For balance you can read the Hudson/Oracle take on it. It's pretty clear to me who is playing defensive and who has real intentions for the project.
As chmullig wrote, use Jenkins. Some additional points:
In fact, arguably it was Oracle who did the forking! And technically, too, that's kinda what happened.
It's interesting to see what comes out of "Hudson" though. While the "Winston summarizes the state and rosy future of the Hudson project" stuff they posted on the (new) Hudson website originally seemed like odd humour to me, perhaps this was a purposeful takeover, and the Sonatype guys actually have some big ideas up their sleeve. This analysis, suggesting a deliberate strategy by Oracle/Sonatype to oust Kohsuke and crew to create a more "enterprisy" Hudson is a very interesting read!
In any case, this brief comparison a fortnight after the split—while not exactly scientific—shows Jenkins to be by far more active of the two projects.
...and a little background info:
The creator of Hudson, Kohsuke Kawaguchi, started the project on his free time, even if he was working for Sun Microsystems and later paid by them to develop it further. As #erickson noted at another SO question,
[Hudson/Jenkins] is the product of a single genius
intellect—Kohsuke Kawaguchi. Because
of that, it's consistent, coherent,
and rock solid.
After the acquisition by Oracle, Kohsuke didn't hang around for long (due to lack of monitors...? ;-]), and went to work for CloudBees. What started in late 2010 as conflict over tools between the dev community and Oracle and ended in the rename/fork/split is well documented in the links chmullig provided. To me, that whole conundrum speaks, perhaps more than anything else, to Oracle's utter inability or unwillingness to sponsor an open-source project in a way that keeps all parties (Oracle, developers, users) happy. It's not in their DNA or something, as we've seen in other cases too.
Given all of the above, I would personally follow Kohsuke and other core developers in this matter, and go with Jenkins.
Just my take on the matter, three months later:
Jenkins has continued the path well-trodden by the original Hudson with frequent releases including many minor updates.
Oracle seems to have largely delegated work on the future path for Hudson to the Sonatype team, who has performed some significant changes, especially with respect to Maven. They have jointly moved it to the Eclipse foundation.
I would suggest that if you like the sound of:
less frequent releases but ones that are more heavily tested for backwards compatibility (more of an "enterprise-style" release cycle)
a product focused primarily on strong Maven and/or Nexus integration (i.e., you have no interest in Gradle and Artifactory etc)
professional support offerings from Sonatype or maybe Oracle in preference to Cloudbees etc
you don't mind having a smaller community of plugin developers etc.
, then I would suggest Hudson.
Conversely, if you prefer:
more frequent updates, even if they require a bit more frequent tweaking and are perhaps slightly riskier in terms of compatibility (more of a "latest and greatest" release cycle)
a system with more active community support for e.g., other build systems / artifact repositories
support offerings from the original creator et al. and/or you have no interest in professional support (e.g., you're happy as long as you can get a fix in next week's "latest and greatest")
a classical OSS-style witches' brew of a development ecosystem
then I would suggest Jenkins. (and as a commenter noted, Jenkins now also has "LTS" releases which are maintained on a more "stable" branch)
The conservative course would be to choose Hudson now and migrate to Jenkins if must-have features are unavailable. The dynamic course would be to choose Jenkins now and migrate to Hudson if chasing updates becomes too time-consuming to justify.
Up front .. I am a Hudson committer and author of the Hudson book, but I was not involved in the whole split of the projects.
In any case here is my advice:
Check out both and see what fits your needs better.
Hudson is going to complete the migration to be a top level Eclipse projects later this year and has gotten a whole bunch of full time developers, QA and others working on the project. It is still going strong and has a lot of users and with being the default CI server at Eclipse it will continue to serve the needs of many Java developers. Looking at the roadmap and plans for the future you can see that after the Maven 3 integration accomplished with the 2.1.0 release a whole bunch of other interesting feature are ahead.
http://www.eclipse.org/hudson
Jenkins on the other side has won over many original Hudson users and has a large user community across multiple technologies and also has a whole bunch of developers working on it.
At this stage both CI servers are great tools to use and depending on your needs in terms of technology to integrate with one or the other might be better. Both products are available as open source and you can get commercial support from various companies for both.
In any case .. if you are not using a CI server yet.. start now with either of them and you will see huge benefits.
Update Jan 2013: After a long process of IP cleanup and further improvements Hudson 3.0 as the first Eclipse foundation approved release is now available.
Jenkins is the new Hudson. It really is more like a rename, not a fork, since the whole development community moved to Jenkins. (Oracle is left sitting in a corner holding their old ball "Hudson", but it's just a soul-less project now.)
C.f. Ethereal -> WireShark
I've got two points to add. One, Hudson/Jenkins is all about the plugins. Plugin developers have moved to Jenkins and so should we, the users. Two, I am not personally a big fan of Oracle's products. In fact, I avoid them like the plague. For the money spent on licensing and hardware for an Oracle solution you can hire twice the engineering staff and still have some left over to buy beer every Friday :)
For those who have mentioned a reconciliation as a potential future for Hudson and Jenkins, with the fact that Jenkins will be joining SPI, it is unlikely at this point they will reconcile.
From the Jenkins website, http://jenkins-ci.org, the following sums it up.
In a nutshell Jenkins CI is the leading open-source continuous integration server. Built with Java, it provides over 300 plugins to support building and testing virtually any project.
Oracle now owns the Hudson trademark, but has licensed it under the Eclipse EPL. Jenkins is on the MIT license. Both Hudson and Jenkins are open-source. Based on the combination of who you work for and personal preference for open-source, the decision is straightforward IMHO.
Hope this was helpful.
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 12 years ago.
I am considering getting VSS and was wondering what were people's thoughts on it in particular?
It's well-known to corrupt data. There are many better alternatives. If you need to match the feature-set and GUI, check out Vault from SourceGear. Free alternatives are numerous --- from the ubiquitous svn to the more modern (distributed) git, mercurial, etc.
Also, TFS is the MS replacement -- if you want MS tools, at least use TFS.
Jeff Atwood has a nice post: Anything But SourceSafe
There is no excuse for using VSS when there are other solutions such as SVN, Git and Mercurial which are better both in terms of reliability and use more modern approach then VSS.
My thoughts:
AHHHHHHHHHRHRHRHGGGEHAGTJH##$#!&#&$!&###!##%^##$%
No. Seriously.
Before I knew how evil it was (newbie dev), I used it. Then, it corrupted an entire project I was working on. What a pile of garbage.
Use Subversion, Git, or Mercurial...for your own sanity.
Microsoft is pushing Team Foundation Server (TFS) as a replacement for VSS. VSS does offer the simplicity of a file based system, but you will spend a good amount of time repairing the database every so often. TFS is a much more reliable server based system. Visual Studio 2010 comes with a client license and a up to 5 person server license of TFS. You are better off putting your money there.
TFS Costs.
Because the question is a license/price issue, you can call 1-800-426-9400, Monday through Friday, 6:00 A.M. to 6:00 P.M. (Pacific Time) to speak directly to a Microsoft licensing specialist, and you can get more detail information from there.
Use TFS, Perforce, or maybe git.
Even if SourceSafe wasn't extremely dangerous to use (corruption, mentioned already)... just having file versions for source control really sucks. It's almost unbelievable that this type of source control is still widely used.
You want changeset or task-based source control. You'll want to easily know what files went into a specific change... not just a bunch of independently incrementing file numbers.
Perforce is VERY fast, and I'm very happy with it.
I use TFS for one major client, and it's been pretty good too. At the time I set up Perforce, TFS required a Server OS and license for that somewhere. I didn't want to have to set up yet another VM, so I went with Perforce.
I'd still easily choose Perforce today, though. That's mostly because I work with multiple platforms. As the main Perforce GUI client uses Qt, it looks and works the same on any OS.
VSS might be the right answer for some situations (e.g.: small group of devs using visual studio, not generally doing concurrent dev, fault tolerant env. (back-ups), etc.). I think the more important question is how your version control fits into your overall dev & release process. VSS and git are conceptually very different things in some very important ways and how your SDLC works is an important aspect of choosing a control system.
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.
Given I'm:
a solo developer using VS2008 Professional
looking for Microsoft-produced source control (I'm aware there are alternatives)
looking to get away from Visual SourceSafe 2005
Is it correct that my only option is to drop ~$8k on Visual Studio Team System 2008 Development Edition ($5,469) + Team Foundation Server ($2,799) - in order to get the TFS version control component?
Reading the answers to other related questions it looks like routes to bringing the TFS price down is to either become a Microsoft Gold Certified partner or to take advantage of the ISV Empower program. I'd welcome any comments related to these options.
The top non-Microsoft solution looks to be Subversion + VisualSVN, but I'd really like to go the all-Microsoft route if I can possibly swing it.
The reason that I'd like to go all-Microsoft is that it's my preference to first try the stock solution, and then later try the alternatives with the benefit of that experience. Also, I've had the rare positive experience with SourceSafe. Or, maybe I'm just a closet MS fanboy. :-)
Also, does the picture change at all when VS2010 comes out?
Thanks!
P.S. I'm downloading VisualSVN now to give that a shot since there's no reason not to.
If you qualify for BizSpark, that comes with TFS.
Given you are an independent developer, and although I fully understand you wish to go the full-on Microsoft route, I can't stress highly enough that using one over the other won't mean as much to you at this point.
When I started using Source Control, I used VSS... much like many others on this site. After about 4 months, I quickly realized that there were many issues with it (namely, that it corrupted every 10 days or so, and that it caused my machine to lag horribly.)
I switched over to SVN and I do have to admit, I'm quite happy with the outcome. When you build your devleopment team to 2,3,4,5... then look into the expense. You'll find that you can get the same affect of Team Suite if you integrate SVN with something like fogbugz, or look at something like CodeSpaces
If you are a solo developer you might not need to go the TFS way. As the product name suggests it is for teams. I suggest take a dive into source control systems like Subversion + TortoiseSVN or Mercurial + TortoiseHg. You could even use a web based source control if it fits your needs, sometime like Launchpad.net
If you would say why you are so hip on getting it from Microsoft, we might better be able to help you?
Give SVN a try. Look at TortoiseSVN, AnkhSVN, and Visual SVN.
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 9 years ago.
Background: I'm a windows developer at MegaCorp(tm) and I am getting new hardware soon.
Question: Are there best practices around setting up my developer software installs?
Details: I've got my main IDE (Visual Studio/SQL Management Studio), but there are also tools that I'm testing out, additional tools I can't live without, and future accomodations.
All my code is stored on a remote server in SourceSafe so I don't need to really accommodate for that, but I'll regularly jump into perl/python/php for separate/side tasks.
The only advice I can give you is set up your machine in a way you need it and you can work with and then save an image so that you can return to that state easily.
Also, don't forget to go and get all your SysInternals goodies. Oh, also remember to export your rss feeds before you upgrade.
You should also install the Windows SDK (which usually doesn't come with VS), as there are many useful tools there that can help during development.
If you plan to use .NET, look into Reflector and LINQPad.
If you plan to use ASP.NET or do any web development at all, look into Fiddler and Firebug
Use a VM image, then the project has a VM image that is version controlled.
Tools and OS are recoverable years later.
Your name will shine on asa voice of sanity and configuration management.
Get rid of SourceSafe
Seriously, don't store anything in SourceSafe. There are many other, better Version Management Systems out there. What's wrong with SourceSafe? I strongly urge you to consider reading the following posts:
http://www.codinghorror.com/blog/archives/000660.html
http://www.highprogrammer.com/alan/windev/sourcesafe.html
http://www.developsense.com/testing/VSSDefects.html
Especially the last one - it goes into lots of detail about the problems with VisualSourceSafe. What should you use instead? Wikipedia has a great comparison of many different Version Management Systems for you to compare. You can look here to find out which ones integrate nicely with Visual Studio.
vim - VI Improved
Beyond Compare - best diff tool.
If you use multiple machines (like
one for dev one for test)
Synergy is invaluable.
If you occasionally need to edit
icons Paint.NET is pretty good.
As everyone else says kill source safe.
I have to agree regarding SourceSafe, whether or not you have the ability to opt-out of using it or not will obviously affect your ability to addopt a new SCM tool but if you can I highly recommenf the free VisualSVN Server for managing subversion and / or hosting repositories.
If you are prepared to pay for the licence you can also buy the VisualSVN plugin for visual studio, as a student I can't afford that but I have used AnkhSVN which integrates with VS through the source control provider APIs providing a nice native looking interface in VS 08
Other tools I can't live without:
TestDriven.NET
DocProject for easy generation of MSDN-style code documentation. I believe it uses sandcastle to do the real work but sandcastle itself is difficult to use and this is the most sane UI over it I've seen and managed to get working without massive amounts of work.
Paint.NET for graphics work
TortoiseSVN is another really good SVN client that I use for doing things like merging to trunk because I am more familiar with the interface and I think it's nicer than AnkhSVN in some areas