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.
ConfigurationNo 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.
TeamCityAfter 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.
DatabaseBy 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".
migration instructions on TC's server configuration administration screen.
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.
JenkinsAfter 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 securityOut 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 notificationAs 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.
DatabaseFrom 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.
ConclusionFirst 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.
In my next post I will configure and build my first project. Stay tuned