1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Gitflow and CI/CD

Discussion in 'HTML, Graphics & Programming' started by PaulStat, Sep 21, 2018.

  1. PaulStat

    Soldato

    Joined: Mar 1, 2003

    Posts: 5,368

    Location: Cotham, Bristol

    I'm trying to get my head around what steps are involved in using Git flow with a CI/CD pipeline (nb delivery not deployment)

    I figured I could have a Jenkins job which is triggered by pushes to the development branch. And another which is triggered when the release branch is merged into the master branch. The below is rough sketch of what I think might be involved. These are Java projects using Gradle as a build tool with multiple subprojects as part of the repository.

    developer pushes changes to subproject remote dev branch

    Jenkins subproject dev branch pipeline
    -----------------------------------------

    1. subproject jenkins job started
    2. run incremental build of subproject
    3. if passed publish snapshot jar and sources to snapshot artifactory repo/else send email to devs
    4. create docker image based on snapshot
    5. push docker image
    6. have kubernetes start up docker image in dev server
    7. run further tests (eg. non functional for performance, veracode scans etc.)
    8. if passed branch development branch in to a new release branch for subproject (version decided at time of creation)/else send email to devs
    9. remove snapshot from project version eg. 1.0-SNAPSHOT becomes 1.0
    10. merge changes into master and tag it with the version and subproject eg. 1.0-serviceX
    11. merge changes into development and up the version to new snapshot eg. 1.1-SNAPSHOT


    Jenkins subproject master branch pipeline
    -----------------------------------------

    1. subproject jenkins job started
    2. run clean build of subproject
    3. if passed publish release jar and sources to releases artifactory repo
    4. create docker image based on release
    5. push docker image
    6. have kubernetes start up docker image in SIT server
    7. run further tests (eg. non functional for performance, veracode scans etc.)
    8. if passed have kubernetes start up docker image in UAT server
    9. run further tests (eg. non functional for performance, veracode scans etc.)
    10. Release ready for manual deployment to Prod

    So the merge into master by the dev pipeline would trigger the master pipeline. I have a number of questions though.

    1. I've put it as an incremental build for the dev pipeline i.e. no clean. Is this a good idea for fast feedback?
    2. On a similar note for fast feedback should this skip integration tests?
    3. If yes would I need another pipeline for a nightly build of the dev branch that includes integration tests. Or would running the integration tests in the master branch be satisfactory?
    4. SNAPSHOTS! I'm not sure how these fit in with Gitflow? Do I need them? If not at step 3 of the dev pipeline I'd start the release branch instead, do another build with the new version publish that to artifactory etc. etc.

    I guess the main part I'm not sure of is if snapshots fit in this picture? Have I been polluted by Maven concepts?
     
  2. Dj_Jestar

    Caporegime

    Joined: Oct 18, 2002

    Posts: 28,283

    Location: Back in East London

    You shouldn't have Jenkins merging into develop/master for you. That should still be a manual process once your devs/team are satisfied that a release or hotfix is ready for release.

    What you could have is jenkins build and deploy (yes, to production) whenever someone merges into master. Or perhaps better is whenever a new tag is added for the version.