0

We are using Assembla ticket system and SVN repository. We are planning to automate the build process using Jenkins server.Would it be possible to trigger the build based on ticket status?

We have 4 different servers

  1. Dev Server
  2. QA Server
  3. Staging Server
  4. Prod Server.

Once the developer completes the coding, he will commit the code and change the ticket status to Assigned for code review, Jenkins will build the commit and deploy it in dev server. The dev team member (reviewer) will do the code review and will test the build in the dev server. Once the code review is completed, the reviewer will change the ticket status to completed code review. We would like to take all the tickets in the completed code review status, build it and deploy it to QA server. The dev and QA server are built from the same branch in SVN. UAT and Prod are built from the trunk.

QA Build should contain only the commits that have passed the code review phase. "Completed code review" is a ticket status in Assembla.

Any help is appreciated.

Regards KK

Mark O'Connor
  • 76,015
  • 10
  • 139
  • 185
user2309846
  • 1
  • 1
  • 1
    You are better advised to setup an automated build based on subversion commits. The Jenkins build number can ensure each build version number is unique. The Assembla Jenkins plugin will link back all changes to the Assembla ticket (provided to commit the ticket number in the subversion commit message). – Mark O'Connor Oct 06 '13 at 10:04
  • Thank Mark for the reply. updated the question with more details. – user2309846 Oct 06 '13 at 18:03

2 Answers2

0

What Mark says. Plus: Why code review something that hasn't been shown to work? If you've got another test job in Jenkins you can hook this into the publish the build work on success.

Dan
  • 358
  • 1
  • 11
0

I would recommend using a binary repository manager (like Nexus) to hold the build output, the files that are normally deployed. Each subversion commit would result in an automated test and save into the repository manager. A downstream job in Jenkins could then automatically deploy this into the development server for automated integration testing.

The advantage of this approach is that instead of creating a certification process within the build system it instead is integrated into the deployment process. The secondary benefit is that each deployment into QA, Staging, Prod systems are always using the same binaries.

It's worth noting that Nexus professional has support for this kind of build promotion process via its staging suite. So this process could be controlled externally using the ticketing system or integrated into the binary repository manager.

Finally, Gerrit is an example of a code review system that has many of the features you're looking for. Unfortunately it only supports Git.

Mark O'Connor
  • 76,015
  • 10
  • 139
  • 185