Dayly Build Concept

Discussions

General J2EE: Dayly Build Concept

  1. Dayly Build Concept (3 messages)

    I am a developer of a medium large company which needs a ERP application. We are about 15 people in the team and we develop this ERP application with Java/J2EE.

    Our integrators need 2 weeks to build a team internal milestone release (including running JUnit tests). This seems to be a long time for me, especially when seing that other teams can do this in a day or so.

    When the version is finally built, everyone needs to check out this stale version and move to the CVS HEAD only on the very few components he is working on. Every piece of resource needs to be tagged (after it has been committed to CVS) with a number of our web issue tracking software. Even if we change a comment, we have to write a issue in our issue tracking software in order to get a number from it with which we can tag the resources (class files mostly). Otherwise our integrators would refuse to integrate it in the next milestone release.

    We are not allowed to use CVS branches. People are allowed to check code into the repository even if it causes compile errors or if it can't be deployed. Its not uncommon that we code against 4 weeks old components of our ERP application. Its because we are not allowed to work on the HEAD.

    I could write more about it, but that should be enough. Well, I am a junior developer with 3 years of experience, but I don't think that this works. Of course we have database scripts for our business objects, so building a milestone version requires in our case a new database schema. It would be easier to build a application which does not need a database very much. But I think that building a milestone version of our ERP application should be finished in a day normally.

    Am I too optimistic? What do you think about this? Is this insanity or am I insane?

    Threaded Messages (3)

  2. Dayly Build Concept[ Go to top ]

    Checkout continuous integration using cruisecontrol or any of the other excellent tools.

    The theory is this:

    every X minutes
     check your source code repository for any changes
     If there are changes
       check out entire source tree
       full build
       full unit tests
       full integration tests if required
       publish reports to central web site/email build failures
     end
    end

    It is not unusual to set up this process to run every 5 minutes or so. The idea being that as soon as anyone checks anything in, the entire test suite is run, and if it fails, the CI process will email/message/shoot the appropriate developer.

    It works best (only) on it's own box, but it is an incredible invaluable tool.
  3. Dayly Build Concept[ Go to top ]

    Hi Colin,

    I feel the same about it.

    What do you think about our process?

    Half of our team (the less powerful ones) feel like me and you. The other half (the leaders, integrators and non-programmers) think that we should isolote ourselves with "defined component versions": programming against defined versions of our own components, which are up to 3 weeks old.

    Software Configuration Managerment is surely not trivial, but I bet that it is not so hard as we make it in our project.
  4. Dayly Build Concept[ Go to top ]

    Is there any other forum you can recommend?

    I never get much answers here!