Search code examples
mercurialcontinuous-integrationjenkins

I want to implement the following workflow for Continuous Integration scenario using Mercurial/Jenkins

The main repository is where all the developers check-in, lets says its located at http://hg.main.com:8000/project

Now, we also have http://hg.qa.com:8000/project where all the LATEST code need to be in Sync, PLUS the tests and other artifacts are in this repository. which will ONLY be "pushed" to central repository if 85% of the tests will PASS.

  1. Is there a better way to implement this?
  2. What hg commands would i need, to make sure that i dont overwrite latest commits
Solution

  • start with something ilke: Approval Management: Auditing and QA

    For whom?

    If you need explicitely approved code history with a full track record using a team of developers and a seperate QA team, this workflow might be right for you.

    Requirements

    You need just Mercurial (command line), a shared repository for exchanging data (a simple SSH-server suffices, as does a single private bitbucket repository) and the GpgExtension.

    Flow

    This workflow uses the default branch for development, as well as a QA named branch and a release branch.

    The advantage is that merging default into QA requires an explicit merge which can subsequently be GPG signed by the developer responsible for it.

    When QA finishes applying their changes, they first of all merge back into default (so that developers work on the QA version) and then merge into release, GPG signing the merge commit.

    Developer

    hg pull # get the latest changes
hg update
hg commit -m ""
hg update -C QA
hg merge default
hg commit -m "merged default branch for QA"
hg sign
hg push

    QA

    hg pull
hg update QA
hg commit -m "QA fixes"
hg update -C default
hg merge QA
hg ci -m "merged QA fixes back into the development branch"
hg update -C release
hg merge QA
hg commit -m "merged finished QA into release"
hg sign

    Modifications

    If you need more layers than just developers and QA, just add additional named branches, for example staging-release before release.

    To make sure that the code has really been checked by all, you can require that all heads must be GnuPG signed in order to enter a higher-up repository.