Example of a CI/CD Pipeline using Jenkins Multi-branch Pipelines hosted at AWS
DevSecOps CI/CD Pipeline Example
Jenkins Multibranch Pipeline
This example uses a [Jenkins multi-branch pipelines]. The code for this pipeline can be found here.
Jenkins multi-branch pipelines build all your branches in your repository under source code control (e.g. github) automatically. Note that you can explicitly include/exclude branch using regular expressions. This allows for a development approach with short-lived feature and bugfix branches that can be build, deployed, and tested simultaneously. This is important, because it allows developers to update and test the pipeline as part of the change request (or bugfix) they are working on, so the pipeline code always stays in sync with the the application code. Furthermore, "standard" development processes can now not only be applied to the application code, but also to the pipeline code, specifically source code control, testing, and code review.
Pipeline Steps
- Build the Java [Spring Boot] application using [Apache Maven]
- Performs a security scan on the Java code base using [SonarQube] via Maven
- Build and register a version of the Docker image
- Deploy the image to the
devenvironment - Run the automated browser tests against the application in the
devenvironment.
- Deploy the image to the
testenvironment - Run the automated browser tests against the application in the
testenvironment - Pause for confirmation that the new image can be deployed to the
prodenvironment.
- Deploy the image to the
prod(or live) environment
Pipeline executions: 
Pause step (step 8): 
SonarQube (security scan) output: 
Note that in the above steps, steps 5 and up in the pipeline are only executed against the master branch. The pipeline code is configured to treat development (feature/bugfix) branches as additional dev environments. These temporary additional dev environments can quickly be created using the application's cloud-formation script and setting the Environment parameter to dev-<branch-name> and the SecurityContext parameter to dev. The new dev-<branch-name> environment now operates in the same security context as the dev environment.
Now when a new temporary development branch is created of the master branch, the Jenkins pipeline will automatically discover the new branch and execute the pipeline code from that specific branch allow a developer to build and test the branch specific changes in isolation, including changes to the pipeline code.
Multiple branch executions (feature1 and master) after creating the feature1 branch: 
Development branch (feature) execution details: 
Development Process
The following outlines how this development pipeline would be used in a (typical) development process:
- A user story (or bug) ticket is assigned to a developer
- Create a temporary and short-lived development (feature/bugfix) branch environment
parameter to dev- and the the SecurityContext parameter to dev. - A development branch is created in the repository using the format feature/<name> or
bug-fix/<name> from the master branch - The developer implements and tests the changes, include new and/or updated automated tests.
- Changes are committed to the branch and tested.
The developer references the ticket in the commit message to allow for integration with the ticketing system, e. GitHub-Jira Integration. - Changes are pushed to the central git server.
- A git webhook triggers the Jenkins pipeline for the feature branch.
- If pipeline build fails, either fix infrastructure issue, or return to step 3
- Manually test the changes
- Once satisfied acceptance criteria are met, create a Pull Request (PR) to the master branch
and assign a reviewer. - Reviewer verifies changes.
- If not accepted, return to step 3
- Reviewer accepts changes, the reviewer or developer merges the PR into
master` and deletes the branch - Delete the temporary development branch environment.
- A git webhook triggers the Jenkins pipeline for the master branch
- Manual tests (if any are executed against the Test environment
- If problems are detected, return to step 3
- Accept changes and push to production
Possible Extensions
- Automate the creation and deletion of temporary development branch environment
- Create separate test suites to allow for a smoke vs. a full suite of tests.
- Application/browser tests are executed against all targetted brower/platform configurations
- Add performance testing in the pipeline, e.g. using [Taurus] and/or [Apache jMeter].
- Penetration tests are executed as part of the pipeline,e.g. using OWAPS' [ZAProxy]
- Integrate a notification mechanism with the pipeline, e.g. Slack
- If an Restful API component is added, use [Newman] to run API tests using [Postman]
How to Install
Installation instructions can be found here).[Jenkins multi-branch pipelines]: https://jenkins.io/blog/2015/12/03/pipeline-as-code-with-multibranch-workflows-in-jenkins/ [ZAProxy]: https://github.com/zaproxy/zaproxy [Taurus]: https://gettaurus.org/ [Apache jMeter]: http://jmeter.apache.org/ [Browserstack]: https://www.browserstack.com/ [Postman]: https://www.getpostman.com/docs/postman/scripts/test_scripts [Newman]: https://github.com/postmanlabs/newman [Newman Docker image]: https://hub.docker.com/r/postman/newman_ubuntu1404/ [Spring Boot]: https://projects.spring.io/spring-boot/ [Python Selenium Webdriver API binding]: http://selenium-python.readthedocs.io/api.html [Apache Maven]: https://maven.apache.org/ [SonarQube]: https://www.sonarqube.org/ [GitHub-Jira Integration]: https://confluence.atlassian.com/adminjiracloud/connect-jira-cloud-to-github-814188429.html [Saucelabs]: https://saucelabs.com/