We all know CI - Continuous Integration and the next step is: CD - Continuous Delivery. Which is a combination of many steps to automate the build, test, release and deploy process.
There are some options we can choose from such as Jenkins or the GitLab Integration (https://stackoverflow.com/questions/37429453/gitlab-ci-vs-jenkins).
We use Jenkins Pipelines (https://jenkins.io/doc/book/pipeline/) because I discovered the GitLab integration too late and at that time the Jenkins process was already finished. Otherwise I would strongly recommend to try the GitLab integration to prevent the "Jenkins Plugin Hell".
(Another alternative is https://de.atlassian.com/software/bamboo)
The goal is to see the CD process as part of the code and not as a seperate part of development. Because of this reason the process is described in script files which are commited to GIT.
Now we have the advantage that we don't need to edit the Jenkins-Job-Configuration everytime we need to change the process. If we have a new server we can (theoretically) easily start our CD process without creating new jobs on the new server.
In the case of Jenkins we need to store a "Jenkinsfile" under the root directory of our project. This Jenkinsfile can be written in the Jenkins-Pipeline language or in groovy or a mix of both.
Jenkins needs to be at least at version 2 (because we need the Jenkins Pipeline)
Following Plugins are needed to get the example Jenkinsfile running
In the Jenkins "Global Tool Configuration" maven needs to be defined:
Following steps are executed
- Update the project/maven/pom version
- Create a GIT-Tag with the new version
- Push the new version to the branch
- Upload the artifact to the Nexus Repository
- Commit the new version to the child/develop branch
- Deploy the new version to the AEM Author and Publish instance
The complete file