Soldato
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?
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?
