13

I need some clarifications on the responsibilities of the Build Script and the Build Server.

I read several articles on the Net about continuous integration and builds. Including

And I had a conversation with my advisor about the build process of our software. Because he is very experienced I trust his statements, but I were left with confusion.

As I understand it, from my research (and please correct me here, since it is what I am asking about) the ideal should be as following:

  • every project has its build script
  • this script builds the project
  • this script makes sure the dependencies are built previously

Since dependencies could be other project, with their own build script a tree-like hierarchy accrues. There may be a top build script which builds all projects and applications.

However the Build Server's responsibilities are:

  • check out the repository
  • trigger the build
  • trigger tests and other QA tools
  • make the artifact available

This may be triggered manually, nightly or whenever the repository changes


The objectives of my advisor are, as I understand them, that one build script is way to inflexible and not maintainable (Aside from the fact that it would take very long from creating one for our legacy code base). Also the Build Server should maintain the dependencies, for example to use older dependencies when creating them new fails. And particular for Ant as it was the concrete subject, is not able to build all kind of different technologies which are used in the code base, and is not able to maintain the dependencies.

Can you please elaborate the objectives, and clarify the responsibilities?

4
  • 4
    As much as this is a good question, and will be answered (I will later when I have time, and it hasn't been answered yet): you should really go back and get clarification from your advisor. Being confused after having a conversation with someone who will be evaluating your performance is a recipe for disaster, and an indication that they are not adequately communicating with you (or you're not actively listening, but that doesn't appear to be the case here). Apr 4, 2013 at 16:36
  • 2
    @Angelo.Hannes I think you've hit all the major points. Can you clarify more specifically what you are confused about? Apr 4, 2013 at 19:05
  • @SteveEvers Well, as did just read some introductions to this topic, I wanted to first expand my knowledge on it. I will then certainly pick this topic up again. Therefore I would really appreciate an answer of yours. Apr 5, 2013 at 6:45
  • @M.Dudley As I said, I am not sure which responsibilities go where. And whether a build script for the whole software is the right way to go. Apr 5, 2013 at 6:49

1 Answer 1

15

These things are orthogonal:

The build script is the mechanism that, upon invocation on freshly checked-out source tree, yields a complete build of required targets and dependencies. It could simply be 'make all' if you've got a makefile, or a suitable invocation of MSBuild, Ant, Maven or Scons. If you have a complex hierarchy of dependencies or related projects, your 'build script' may be a top-level file that invokes each of them in turn, checking for success as you go.

The build script is just one script of possibly many - checkout, build, test, package - but you could have an all-in-one mechanism controlled by command line params - it depends on your environment.

The build server, or rather continuous integration server, is the automation mechanism responsible for scheduling/triggering, monitoring and reporting of the checkout -> build -> test -> package -> stage -> deploy pipeline. You could use cron/Task Scheduler if you had nothing more sophisticated to hand, but there are many excellent tools now such as Jenkins, Cruise Control, TeamCity, etc.

It is important that you can invoke a build without using the CI server, in the case that it is busy/offline/unreachable/otherwise-unavailable, so therefore the logic to get the build/test/whatever done needs to be outside of the CI system, but is invokable by it, parameterized by branch/build type/version/architecture, etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.