Now we will demonstrate how to use it: a developer can create an application that will be compiled, then built and deployed into a test environment automatically using this CI/CD toolset.
Next picture shows the list of operations automated by the CI/CD.
 |
| Application deployment: sequence of automated operations |
These are the lifecycle steps that we will demonstrate in this post:
1. Deploy the PetClinic application (introduced in the previous post) automatically.
2. Push the java source code to a repository (SVN).
3. Creating the next release of the application by modifying the java source code and saving it as a new version in the repository.
4. Watch the Jenkins orchestrator create the new build, save it in the binaries repository (Artifactory) and use CloudCenter to deploy it.
1 - Deploy the PetClinic application automatically.
We start by deploying the Java application PetClinic, using the Application Profile created in CloudCenter, into our development environment in the lab. The correct behavior of the application is tested by accessing its home page and verifying that it shows correctly in the browser.2 - Push the java source code to a repository (SVN).
We then push the java source code of the PetClinic application into the repository (SVN) that was created in our previous task, committing it as the initial release of the application. |
| Source code control: committing the java code into the SVN repository |
An automated build of the application and its deployment follow, as explained by the workflow above, thanks to the Jenkins orchestrator and CloudCenter. If we access the Jenkins GUI (see next picture) through a web browser and we select the project “repo1” we can see that Jenkins is currently creating a new build: look at the progress bar. As soon as the building process is terminated the binaries are copied into the Artifactory repository of binary files and the Jenkins process called “deploy” starts.
 |
| Jenkins: following the build process |
If we access the “deploy” job in Jenkins, we can see that a new build of the PetClinics application has been sent to CloudCenter to be deployed. This is made possible by the plugin that integrates Jenkins with Cloud Center.
 |
| Jenkins: deployment of the PetClinics application through CloudCenter |
 |
| Cloud Center: viewing the deployment details of the deployed PetClinic application |
 |
| PetClinic: home page of the deployed application |
3 - Creating next release of the application by modifying the java source code and saving it as a new version in the repository.
Let’s assume now that another developer is working at improving the front end of the application and he is ready to commit a major chunk of code. For the sake of the demonstration we will only change the picture and the text on the homepage but we will show that, as soon as we commit the modifications to SVN, the new application is automatically deployed in the Development environment via Cloud Center (as you already know, the Development environment could be in any on-premises/hosted private or public cloud). |
| Application lifecycle: creating a new version of the code of PetClinic |
We will modify the file petclinic/src/main/webapp/WEB-INF/jsp/welcome.jsp changing the text and the pet image (see next picture). Once we are done we save the new version of the file and commit it (right click, SVN Commit). After waiting a few minutes for the whole chain of operation to finish, we will find out a new deployment of the application in Cloud Center –> Projects –> Project PetClinic Now we can navigate the application, in the test environment, to see how the new release looks like: you can see that the puppy picture and the text message have been updated according to the edit done by the developer.
 |
| PetClinic: home page of the modified application |
Conclusion
The two use cases shown in this series of posts:
• creation of a CI/CD environment as a service, and
• automated Deployment of every new release of an application
demonstrate the power of CloudCenter as an orchestrator in deploying applications across a multicloud environment.
Every stage of the project (dev, test, prod…) can be associated to a different deployment environment, potentially in different clouds, having its own set of configuration, policies and rules. This information is stored in CloudCenter as part of the governance model you build for your IT.
The application will move automatically from one phase of the project to next one, if it passes the specific tests (i.e. integration, functional and performances tests, run by the automation tool) after each deployment.
In future posts we’ll show how to also automate these tests in a CI/CD pipeline.
We will use open source tools like Apache Jmeter to run functional tests designed together with the application and automated by scripts stored in the same source code repository.
And we will run performance tests with the same tool, of course after CloudCenter has moved the deployment to a target environment that is able to sustain the load we generate.
Credits
This post is co-authored with a colleague of mine, Stefano Gioia.
References:
CloudCenter
