Comparing Jenkins vs TeamCity - Part 2
This is a second installment in a series of posts that tries to compare two continuous integration and build automation server products. In my previous post I briefly introduced the contenders open source developed Jenkins and a commercial offering from JetBrains called TeamCity and compared their respective installation experience.
This time I'll try to cover the post-installation configuration steps I need to make before I can start putting some builds into them.
This is just a first page of the initial set-up wizard:
After this really simple initial set-up wizard you're basically configured with a simple authentication scheme, have created one administrative account and are ready to go.
However, not everything is configured, as is also suggested by the projects initial project overview page.
In Out of the box configuration you can set up your e-mail and Jabber notifications. Just follow the link that says "configure email and Jabber settings" in the Overview page.
It leads you to Administration > Server Configuration section.
Then click on the "EMail Notifier" tab, fill in your e-mail SMTP gateway details, press "Test connection" to ... well, test the connection. and if it checks out, press "Save".
If you use internal (or external) Jabber service for instant communication, you can also set it up by filling out a similar form under the "Jabber Notifier" tab.
JetBrains nicely offeres a link to migration instructions on TC's server configuration administration screen.
Basically there are two ways to migrate.
The second one is what you'll do if you have run for a while, have some projects and users configured, etc. In short, if the current DBMS you has some data, you do not want to lose and you need to migrate it to another database for whatever the reason.
TeamCity supports HSQLDB, MySQL, Oracle, PostgreSQL, Microsoft SQL Server 2005, 2008 and Sybase; the migration is possible between any of these databases.
Migration in general is a tedious process, involving backing up data, stopping and re-starting server(s) and generally doing lots of manual labor. The authors of TC have done a fairly good job of explaining it all.
Out of the box configuration of Jenkins allows you to pull your sources from CVS, Subversion and local filesystem; build Ant or Maven driven java builds and execute shell/command line commands and scripts.
So if all you need is a local build server instance in your machine, to build your java projects, you're pretty much done.
Still there are some things missing from the default configuration that are sort of mandatory, if you are working in a team and building up your CI system in earnest.
It is probably just okay in a small company or department's internal closed network setting, or as a personal server, where everyone is fully trusted to do the right thing and not to mess up a production grade build automation. However as soon as your build server has to have public/internet availability you'll need to start turning down those knobs and that is where additional security measures come in handy.
Setting up basic security isn't hard:
I must however point out that the vanilla installation of Jenkins comes only with few user authentication options, but you can install additional methods from it's extensive set of authentication plug-ins
Like everything that has a configuration setting, Email notifications section is on the System Configuration page. Just open by navigating to Manage Jenkins → Configure System, scroll to the bottom of the page to the "E-mail Notification" section, fill in your SMTP gateway details (if your SMTP server requires logon, do not forget to click on "Advanced" button and fill in those advanced e-mail settings)
Test the configuration and press "Save". Pretty much same as TC.
At the very least what I would like to see is a nice friendly reminder in a dashboard, that says something to the effect "This copy of Jenkins is completely unprotected". You could dismiss it if it bothers you, but it should be visible at least the first time you visit unsecured Dashboard of a freshly installed/updated Jenkins instance.
A nice touch of the TeamCity was the "unsaved changes" notification at the bottom of the browser window when you had modified something, but had not hit the "Save" button yet. It served a double purpose of reminding you that you had unsaved changes on the form and offered a nice easy access to the "Save" action.
Overall, here is where TC commercial backing shows - the overall out of the box experience is somewhat smoother and nicer than Jenkins's.
Enterprises will love the fact that TC keeps it's data in an SQL database and the lineup of supported databases should satisfy any corporation, but the simplicity of persisting data in XML files is just barely short of genius - Developers (and dare I say, sysadmins) will love this.
The set of minimal post-installation configuration steps will vary by use case for either, but both products make it rather painless process and all things considered I'd like to give this step a tie.
In my next post I will configure and build my first project. Stay tuned
This time I'll try to cover the post-installation configuration steps I need to make before I can start putting some builds into them.
Configuration
No server software is usually useful out of the box in and by itself. You almost always need to tweak and configure it before you can really reap the benefits. Continuous integration is just another type of server and it needs to be configured before it becomes really useful.TeamCity
After you've installed your copy of TeamCity and opened up it's web interface for the first time, it greets you with a nice little license agreement, you need to agree to in order to be able to continue.This is just a first page of the initial set-up wizard:
- License agreement: Check "agree" and press Continue
- Fill in details for admin user account and press "Create account" button
 |
| Initial Overview screen |
However, not everything is configured, as is also suggested by the projects initial project overview page.
Email and IM notifications.
One of the nicest things about CI services is that they can notify you proactively if you need to know of some important events like builds or test failing or some such. |
| Email notification settings |
It leads you to Administration > Server Configuration section.
Then click on the "EMail Notifier" tab, fill in your e-mail SMTP gateway details, press "Test connection" to ... well, test the connection. and if it checks out, press "Save".
If you use internal (or external) Jabber service for instant communication, you can also set it up by filling out a similar form under the "Jabber Notifier" tab.
Database
By default, the TC installation comes with embedded Hypersonic SQL DB (HSQLDB for short). It is a good database in it's own right and has it's strengths in the situations where you would need a fast and tightly integrated in-process DBMS embedded into your Java application, but running a production server on HSQLDB is ... well lets just leave it at "it's just not done all that often".
Basically there are two ways to migrate.
- Wipe TC data location, specify new db configuration and essentially re-configure your instance
- Full data migration
The second one is what you'll do if you have run for a while, have some projects and users configured, etc. In short, if the current DBMS you has some data, you do not want to lose and you need to migrate it to another database for whatever the reason.
TeamCity supports HSQLDB, MySQL, Oracle, PostgreSQL, Microsoft SQL Server 2005, 2008 and Sybase; the migration is possible between any of these databases.
Migration in general is a tedious process, involving backing up data, stopping and re-starting server(s) and generally doing lots of manual labor. The authors of TC have done a fairly good job of explaining it all.
Jenkins
After you've installed Jenkins in the manner outlined in a previous article, you can open your browser, point it at the http://localhost:8080/ and you are presented with a Dashboard, where you can immediately start by adding new build projects.Out of the box configuration of Jenkins allows you to pull your sources from CVS, Subversion and local filesystem; build Ant or Maven driven java builds and execute shell/command line commands and scripts.
So if all you need is a local build server instance in your machine, to build your java projects, you're pretty much done.
Still there are some things missing from the default configuration that are sort of mandatory, if you are working in a team and building up your CI system in earnest.
Basic security
Out of the box installation of Jenkins has no security whatsoever. In essence it is a public free-for-all build server, where anyone has full access to alt the builds, full configuration and all of the operational details.It is probably just okay in a small company or department's internal closed network setting, or as a personal server, where everyone is fully trusted to do the right thing and not to mess up a production grade build automation. However as soon as your build server has to have public/internet availability you'll need to start turning down those knobs and that is where additional security measures come in handy.
- From Dashboard: Manage Jenkins → Configure System
- Check "Enable security"
- Select how your users will be authorized (e.g. LDAP or Jenkins's own database)
- Choose the level of security you'll feel comfortable with
I must however point out that the vanilla installation of Jenkins comes only with few user authentication options, but you can install additional methods from it's extensive set of authentication plug-ins
Email notification
As with TC you need to configure your e-mail gateway before it can start sending e-mail notifications.
Test the configuration and press "Save". Pretty much same as TC.
Database
From all that I've seen (not that I looked too deep), Jenkins does not use any SQL database for persisting it's state - using custom XML based persistence instead. This is good, because this means you can do ton of things with the data, like store it ins some VCS, clone settings into new Jenkins instance, back it up, script it up, etc.Conclusion
First difference I noticed is that the first thing TC did was to create an admin account and thus secure your TC server installation.One might argue if it is a good thing or not either way, but the fact is that the very first entry on Jenkins best practices page recommends "Always secure Jenkins.".At the very least what I would like to see is a nice friendly reminder in a dashboard, that says something to the effect "This copy of Jenkins is completely unprotected". You could dismiss it if it bothers you, but it should be visible at least the first time you visit unsecured Dashboard of a freshly installed/updated Jenkins instance.
A nice touch of the TeamCity was the "unsaved changes" notification at the bottom of the browser window when you had modified something, but had not hit the "Save" button yet. It served a double purpose of reminding you that you had unsaved changes on the form and offered a nice easy access to the "Save" action.
Overall, here is where TC commercial backing shows - the overall out of the box experience is somewhat smoother and nicer than Jenkins's.
Enterprises will love the fact that TC keeps it's data in an SQL database and the lineup of supported databases should satisfy any corporation, but the simplicity of persisting data in XML files is just barely short of genius - Developers (and dare I say, sysadmins) will love this.
The set of minimal post-installation configuration steps will vary by use case for either, but both products make it rather painless process and all things considered I'd like to give this step a tie.
What's next
In my next post I will configure and build my first project. Stay tuned
Comments
I can only say as much that although I liked the TeamCity polish in many areas, the closed infrastructure and significantly smaller community mindshare prompted me to prefer Jenkins over TemCity.
I surely hope to finish this serias some day, but I have no idea, when if that day may come...