Ars Gratia Artis

So, I came out of retirement to work on a neato project. I’m doing a lot of programming, architecture, release management, project management, and, um, reporting. So, that’s why I’m not doing a whole lot of bagpiping or anything. Because this is fun and important.

But nobody cares about that. The interesting thing here is that when I came on board there was git and not a whole lot else in the way of engineering support. I know how horribly messy a build and release system can get, let alone a development workspace, without some good process and support tools in place. So I started thinking about continuous integration, bug tracking, and an artifact repository.

I then mentioned this in a work context and was reminded that a “team” of only three people probably didn’t need a CI system and an artifact repository, but maybe a bug tracker wasn’t a bad idea. And that made sense. I have worked with enough QA people, though, and people who were serious and thoughtful about configuration management and build/release process, to still feel like having a dedicated build machine is probably a Good Idea. I just feel kind of itchy when I think about distributing software that was built on a programmer’s laptop.

So I checked out Jenkins and Artifactory and became befuddled within an hour of crawling through their documentation. I have associated with CM folks, but I’ve never really figured out their lingo.

Time passed. I wrote a lot of code. Other folks did. We threw some stuff away, we built some stuff, and now we’ve reached a major internal milestone. I’ve released some software internally, and it was built on my laptop. By me. By opening a terminal window and typing `mvn package`. I still kind of cringe to think about that, even though when I go to the trouble of articulating why, it turns out that in this particular case it is okay. I’m distributing an early beta/late alpha dev build.

Anyway, tonight I had a bit of spare time. Did I play video games? Did I veg out to some Netflix? Or did I install Nexus and TeamCity and try them out? Yeah, you guessed it. I still don’t think that we need an artifact repository. Not yet, anyway. We don’t have enough distinct modules to need it (unlike at Netflix, where we had a score or more internally developed libraries). But I found that setting up TeamCity was really easy (well, except for the part where it doesn’t grok my local MySQL installation) and it doesn’t confuse me with a lot of words that don’t mean what I think they mean. I might actually turn our cute itty bitty Mac Mini into our build server. Won’t that be a kick?

You know. For fun.

Published by pirateguillermo

I play the bagpipes. I program computers. I support my family in their various endeavors, and I enjoy my wonderful life.

3 thoughts on “Ars Gratia Artis

  1. At work I’m currently going around devops to get a mac mini set up as an xcode build server – cause they just don’t seem to get around to it.

    Yeah, jenkins learning curve is about like a brick wall – but the good news is that it’s a pretty short wall. Once you get over it, it levels out pretty quickly.

    I’d never heard of Nexus or TeamCity. Still not quite sure what they do or how – even having looked at their websites.

    1. Nexus is an artifact repository. It has lots of features but so far as I can tell it’s principally interesting for two reasons:
      1) it acts as a maven repository to which your build server can publish artifacts
      2) it acts as a caching proxy for any number of remote repositories

      1 means that I don’t have to pull the code and build the libraries from all the other groups in my organization when all I really want to do is build the main app and link in their stuff. That’s great when engineering has like 300 programmers, but maybe not so interesting when there are only 2.

      2 means that all those weird repos hosted on DSL in some eastern European country can be mirrored in the corporate repo and the artifacts only have to be fetched once.

      TeamCity is a build system, like Jenkins. From my hour of fooling around last night, it seems easier to get up and running than Jenkins, and it’s really easy to get it naively integrated with our GitHub repos. I suspect it will be way trickier to get it configured to watch “dev” instead of “master”. There’s also a plugin for IDEA that integrates IDEA with TeamCIty and I haven’t poked at that yet so I don’t know what-all is available there. Maybe something interesting, or maybe just agile bogosity.

      1. One of the things I love about jenkins is how easy it is to tweak configurations after you have it working. I have about half a dozen jobs set up for the same git repo. Any time anything is committed, the tests are run.

        We use git flow – which means that different branches mean different things. In addition to testing, any time something is committed, the integration environment is deployed. Any time the dev branch is merged to/committed to, the test environment is deployed. Any time a release or hotfix branch is committed, the staging environment is deployed. And I have a one button deployment for production just because I want to keep an eye on it while it goes out the door.

        It all just hums along without my having to think about it.

Leave a ReplyCancel reply