The other one is the application source code. The output from unit and integration tests is a coverage report, which will be one of the artifacts used by Sonar server to generate quality metrics. The integration tests are considered a success when all requests were validated against the application deployed in the test environment. In this case, the test framework creates all the infrastructure needed for the tests: an in-memory database with test data and a small web server to deploy the application. If nothing goes wrong during the unit tests, the pipeline flow initiates the integration tests. After updating the project’s version, Jenkins starts building the source code using Maven.Īfter a successful compilation, the pipeline will perform unit tests. Later, can be used as a metric and process control. This way, we have a fingerprint of this build during deployment. The next thing to do is to update the project version according to the build number (e.g. The process starts by pulling the application source code from Github. The implementation details of this pipeline can be seen in this repository. Note that the purpose of this pipeline is for demonstration only and may lack steps that a real-world CI/CD process might have. Now that the tools and the architecture of this lab are well known, let’s explore the CI/CD pipeline flow built for this lab. Details about how this was done could be seen in the project Vagrant ALM at Github. The environment for the virtual machines in this lab was managed by Vagrant with libvirt. Spoiler alert: Ansible Galaxy will be your primary source to learn Ansible. If you are new to Ansible, check this article about how to get started. More about this Playbook is discussed further in this article. To put this infrastructure together, we built an Ansible Playbook using roles from the Ansible Galaxy community. It is responsible to put all the pieces together, resulting in the application successfully deployed in the target machine. Jenkins is our CI/CD process orchestrator. The Ansible Playbook, which is a YAML file integrated in the application source code, deploys the Spring Boot App on to a CentOS machine. Later those binaries will be downloaded by Ansible during the application deployment. After a successful compilation, unit tests and quality analyses, the binaries are uploaded into it. This step is important to guarantee the source code quality index. not enough unit tests), the flow is interrupted. If anything goes wrong during the analysis (e.g. SonarSource is our source code analysis server. Github is where our project is hosted and where Jenkins will poll for changes to start the pipeline flow. It has some elements of ALM (Application Lifecycle Management) to emulate a real-world scenario and apply our CI/CD demo pipeline flow.įigure 1 - Infrastructure architecture components overviewįigure 1 illustrates the following architectural elements: Jenkins to orchestrate the CI/CD pipeline flowĪnd finally, Ansible to create all infrastructure for this lab and the to provision the applicationįigure 1 illustrates the overall architecture for this lab. Nexus is the repository for artifact binaries GIT for source code management and control SonarSource to bring up quality analysis to the CI/CD process Vagrant and libvirt to create the infrastructure for this lab The tools used to create the examples for this post are: The purpose of using Ansible in the pipeline flow is to reuse roles and Playbooks for provisioning, leaving Jenkins only as a process orchestrator instead of a shell script executor. Although this could work, it is cumbersome to maintain and reuse scripts in the long run. Shell scripts are commonly used for provisioning environments or to deploy apps during the pipeline flow. Jenkins is a well-known tool for implementing CI/CD. The aim of this post is to demonstrate how to use Ansible for environment provisioning and application deployment in a Continuous Integration/Continuous Delivery (CI/CD) process using a Jenkins Pipeline.Īnsible is a powerful tool for IT automation and can be used in a CI/CD process to provision the target environment and to then deploy the application on it.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |