Responsibilities of Build Script and Build Server

buildscontinuous integrationversion control

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?

Best Answer

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.

Related Topic