≡ Menu
Pawel Brodzinski on Software Project Management

Best Practices: Continuous Build

Best Practices

Under my recent post about best engineering practices I was pointed that it is just another “do whatever works for you” or I don’t know experiment kind of advice. Well, it was that kind of advice indeed. Have I ever given you a different one?

Anyway I admit shot was on target. If someone is one of those battlescars who has seen much they probably would be more than happy to hear something like that. On the other hand if you happen to be a freshman you may expect to get something like a real advice. You know, the one which you can simply take and apply in your team without much thinking since “the wise guy said so.”

Coming back to best practices than. What can I tell you besides you should experiment with your practices to find what works for you? Well, if I had to choose one engineering practice which is definitely a sure shot I’d go for continuous integration. And yes, I’m not expecting a flame war under this post.

“Who the hell doesn’t have continuous build yet? We are in 21st century, haven’t you heard?” Yes, I used to treat continuous build as an obvious thing a decade ago and you know what? I was wrong. There are many teams and companies which don’t have continuous build implemented. Why? Because they think it is hard, because it takes time to setup the whole thing, because the project is oh so legacy, because no one cares, because no one approved order for build server, because, because, because… If you want to hit the dog you will find a stick. And many companies are still beating poor puppies hard. I could name huge systems sold to big institutions which never touched a build server.

I can tell it as an anecdote: pretty much every company I worked for set up continuous build once I was working for them. This basically mean the earlier you hired me the better. Not that every company I’ve worked for still exists but we aren’t discuss business here, are we?

If I think about setting up a team or project the very first task to do is getting and configuring a build server. It is a prerequisite to write a first program. And I’m not going to take a look at damn hello world application until build server is up and running. Don’t even say you dared to write any code without continuous build set up.

So this is my first answer about specific engineering practices we all should employ. Unfortunately once I started to give you specific answers I expect to hear “what’s next?” And from this point every answer can be only more difficult.

That doesn’t mean I won’t try though.

in: software development

4 comments… add one

  • jfbauer June 11, 2010, 5:53 pm

    Sage advice … anyone work for a large corporate IT shop and achieved a relative continuous performance/functional test environment/methodology? I’d love to hear from you.

  • Pawel Brodzinski June 12, 2010, 1:49 am

    Well, I used to work in this kind of environment. It was a bit easier because we were working in silos so we cared only about out silo, which was like 100 engineers.

    I have a couple of friends working for a local branch of a big shop and they have engineering side of their work organized well. At least in terms of continuous integration. This isn’t my personal experience though.

  • Szymon Pobiega June 14, 2010, 1:51 am

    I think you expected me to comment about that, Pawel;) To clarify, I like continuous integration. But integration is way more, than building. If you don’t have _good_ unit/integration tests, having a build server gives you close to nothing.

    I recently worked on a team where we had a set of unit tests covering over 90% of our code, and (at least in my opinion) these tests were of good quality. We had a habit of first executing all the tests, then committing to source control system. It worked for us. We were all the build servers. For the team of 3 people sitting in one room is was enough.

    But as you said many times, collocation solves many problems that otherwise need sophisticated tools.

  • Pawel Brodzinski June 14, 2010, 3:15 am

    Yes, build server alone is not continuous integration. It is just a starting point. On the other hand, besides your example, I know no teams which deals well without build server in terms of test automation, code analysis etc.

    I consider continuous build as a starting point and prerequisite for many other engineering practices. You may run without build server at the moment but I’m sure if you were starting the project once again you would setup one. I’m also not so sure it wouldn’t make sense to get one for the project now. You can’t be sure how long all of your team members would be in place. What if someone leaves? I think newbies would appreciate having build server.
    And this is always good for testers too.

Leave a Comment