With multiple developers on the project and tight deadline, often is the case that some developer makes a commit that cannot be built, all the tests do not pass, or they simply do not exist, the built artefact works in one environment and not the other. These problems are common, but they can be detected or avoided with automated CI/CD tools.

For this demonstration I use three environments, development, test and production. The development environment contains latest built artefact, the test environment contains tagged version with a release candidate mark, while the production contains a tagged version without a release candidate mark. Tools are GitHub for version control, Jenkins for automation, SonarQube for static code analysis, Nexus for artefact storage, and Ansible for deployment. There are other tools who provide the same or similar functionality, such as DevCS (Oracle Developers Cloud), which integrates all above tools into one.

We did everything step by step. Developers in cooperation with the release manager make a change to the code and commit and push these changes to a dedicated branch inside a GitHub repository. GitHub via a configured webhook informs Jenkins that a new commit is available on a specific repository. Jenkins automatically checkout that commit and execute actions defined in a file with JenkinsFile filename. That file contains all the commands needed to run build and unit tests, send code to SonarQube for static analysis, publish built artefact to Nexus with the version that contains the commit tag and deploy that artefact to the development environment with Ansible deployment tool. If any of the above actions fails, Jenkins will automatically notify all the members of the team about the failure through a dedicated Slack Channel. After notification is received, team can investigate and repair problem. This simple workflow is called build workflow and allows you to quickly and easily detect problems with build and code quality, mentioned at the beginning of the article.

A problem that cannot be avoided with a single workflow is when builds that work in the development environment don’t work on test or production environments. You solve this with single build, multiple deploy. Basically, artefact for deploy is built and published to Nexus only once during build workflow and during deploy workflow is deployed to a desired environment only. This workflow can be triggered with git semantic tagging.

For example, a developer or a release manager creates a tag for specific commit with a name v{MAJOR}.{MINOR}.{PATACH}-rc.{SEQUENCIAL_NUMBER}, this tag is detected by Jenkins which starts deploy by downloading artefact from Nexus, incorporating environment specific properties inside an archive and deploying it using a Ansible deployment tool. Test environment next – if it works it is done. A developer or a release manager creates an additional tag for the already tagged commit, but this time with a semantic name v{MAJOR}.{MINOR}.{PATACH}. This is a sign to Jenkins that the build is ready for production. Jenkins doesn’t not build or test commit, just downloads artefact from the Nexus and deploy it to the production with Ansible tool.

With those two workflows and little initial effort to set up the environment, a development team can easily detect and avoid problems listed at the beginning of the article.

If you would like to further speed up and take care of your development environment by someone else, it is possible to use DevCS (Oracle Developers Cloud) tool that contains all the tools I’ve talked about. In any case, speeding up detection of problems or avoiding them completely can only contribute to your business.