It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,850

question asked: May 12 '09, 9:21 a.m.
question was seen: 6,403 times
last updated: May 12 '09, 9:21 a.m.

Related questions

Continuous Integration with Team Concert

0
Sébastien Alonzo (56●1) | asked May 12 '09, 9:21 a.m.
Hello,

This topic may have already been covered in another post but I couldn't find it.
If I missed it somehow, I apologize for the redundancy.

I'm a new user of RTC and even if I'm convinced of the huge added value of the Jazz platform compared to alternative solutions (such as JIRA/Subversion/Hudson+Maven), I still miss some key features for proper continuous integration.

For me continuous integration should be a formidable mean of control to ensure the best possible quality of your code with the best possible productivity. It means the code shared between team members should remain stable at all time and any problem should be detected and fixed as quickly as possible.

Hence, a typical build engine (such as Hudson) should be able to :

  1. poll the SCM for changes (e.g. every 15 minutes)
  2. fetch theses same changes
  3. run a Maven build (e.g. 'clean install
') to check that the latest version of the code compiles properly and that all unit tests pass.
  • in case the build is broken (due to compile errors or failing tests) : notify the team lead, along with all developers responsible for the changes that triggered that build (if the previous build was successful, we can reasonably conclude that one of them has committed a change that caused it to fail)

    • With Hudson, this notification is sent by mail and it's even possible to customize the message content to include the changes that triggered the build as well as the failed tests (if any). The key to success being that only developers that are supposed to fix the problem are notified. Therefore there is a good chance that the build won't remain broken for long.

    It seems to me that with Jazz every developer is notified after every build (successful or not) so there is a good chance that the culprit won't notice the problem (or just think that it may be due to somebody else's mistake)

    So far I was able to create a build definition that will poll the SCM to track changes delivered to a given Stream, then run a Maven build and even publish JUnit test results (using Jazz Ant tasks).
    Unfortunately I could not find any way to notify the developers who delivered the latest changes and this only in case of failure (either by mail or with a Jazz event)

    Am I missing something ?
    If not, what are best practices for implementing continuous integration with Jazz ?

    Thanks for any help,
    Sebastien

    6 answers

    Most liked answers ↑|Newest answers|Oldest answers

    0
    permanent link
    Sébastien Alonzo (56●1) | answered May 15 '09, 12:18 p.m.
    Hello again,

    I'm a little surprised that nobody replied to that topic at all.

    Am I the only one with such concerns ?
    0
    permanent link
    David Olsen (523●7) | answered May 15 '09, 1:48 p.m.
    JAZZ DEVELOPER
    salonzo wrote:
    Unfortunately I could not find any way to notify the developers who
    delivered the latest changes and this only in case of failure (either
    by mail or with a Jazz event)

    You are correct that RTC can't be configured to automatically send an
    e-mail message to everyone who contributed to a build that failed. But
    that is the only thing missing from your wish list.

    Am I missing something ?
    If not, what are best practices for implementing continuous
    integration with Jazz ?

    I see two things that contribute to this lack of automatic build failure
    e-mail not stopping people from using RTC for continuous builds.

    1. The information about who contributed to the build is readily
    available in the build result, grouped either by work item or by change
    set. The person who oversees the builds can very easily fire off an
    e-mail message to all the contributors, or open a work item and
    subscribe all the contributors.

    2. Personal builds make build breakages less likely. Developers can run
    a personal build that duplicates the official build in almost every way.
    There is no good excuse any more for delivering a change that will break
    the build.
    0
    permanent link
    Ralph Schoon (63.3k●3●36●46) | answered May 17 '09, 11:04 p.m.
    FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
    Hello salonzo,

    I'd suggest to create a work item. I am not sure what you request can be
    done with RTC today.

    Ralph

    Hello again,

    I'm a little surprised that nobody replied to that topic at all.

    Am I the only one with such concerns ?
    0
    permanent link
    Sébastien Alonzo (56●1) | answered May 18 '09, 6:50 a.m.
    Hello Ralph,

    I agree with you and a colleague of mine has already created a work item for that (Enhancement 83264)
    I hope it will be considered as a relevant enhancement for RTC 2.x

    Thanks for your answer anyway.


    I'd suggest to create a work item. I am not sure what you request can be
    done with RTC today.
    0
    permanent link
    Sébastien Alonzo (56●1) | answered May 18 '09, 7:10 a.m.
    Hello David,


    1. The information about who contributed to the build is readily available in the build result, grouped either by work item or by change set.
    The person who oversees the builds can very easily fire off an e-mail message to all the contributors, or open a work item and subscribe all the contributors.

    I agree it could be a manual workaround but it's really a shame to have someone dedicated to such a monitoring when it could be automated.
    Isn't increasing team productivity one of the main goals of Jazz ?



    2. Personal builds make build breakages less likely. Developers can run a personal build that duplicates the official build in almost every way.
    There is no good excuse any more for delivering a change that will break the build.

    Even when he doesn't use Jazz for Personal builds, any developer can run maven on its own computer prior to a delivery to ensure his change won't break anything. So as far as I'm concerned there is never a good excuse to deliver bad code.
    Unfortunately it happens all the time in real life (it could be an occasional mistake or it could reflect a lack of competence due to hiring cheap developers for the illusion of making a bigger profit) so that's something we have to monitor.

    But I agree with you, almost all the items from my wish list are provided with RTC, which is a good thing. Unfortunately I really need all of them to do proper continuous integration.

    Thanks for taking the time to answer this post.
    0
    permanent link
    Evan Hughes (2.4k●13●18) | answered Jun 01 '09, 4:09 p.m.
    JAZZ DEVELOPER
    I've put together a wiki page describing how to notify users when a build breaks. It shouldn't be considered supported, nor should it be considered final, but it will likely be of interest to the folks reading this topic.

    See https://jazz.net/wiki/bin/view/Main/SCMUsingTheCliInBuilds.

    If you have problems or questions, please add a comment to https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/80767.

    It relies on some 2.0-only functionality, but you can probably fake it with 1.x.

    Your answer

    Register or to post your answer.


    Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.