Thursday, February 03, 2011

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.


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.


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:
  1. License agreement: Check "agree" and press Continue
  2. Fill in details for admin user account and press "Create account" button
Initial Overview screen
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.

    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
    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.


    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".

    JetBrains nicely offeres a link to migration instructions on TC's server configuration administration screen.

    Basically there are two ways to migrate.
    1. Wipe TC data location, specify new db configuration and essentially re-configure your instance
    2. Full data migration
    First choice suits you perfectly if you have just installed your first instance of TC and want to store the data in something else than HSQLDB.

    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.


    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.

     Setting up basic security isn't hard:
    1. From Dashboard: Manage Jenkins Configure System
    2. Check "Enable security"
    3. Select how your users will be authorized (e.g. LDAP or Jenkins's own database)
    4. Choose the level of security you'll feel comfortable with
    Hit "Save" at the end of the page (if that is all you needed to configure), and you are secured.

    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.

      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.


      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.


      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
      Post a Comment