Devops Project: Medical Platform Application

Deployment via CI/CD

Name: Shashank Singh

Email: [email protected]

1. Introduction

This report summarizes the successful deployment of a simple medical platform application,
achieved through the implementation of DevOps principles and a robust Continuous
Integration/Continuous Deployment (CI/CD) pipeline. The project utilized a standard, well-supported
technology stack including Git for version control, Maven for the build process, Jenkins for CI/CD
orchestration, Docker for containerization, Ansible for deployment automation, and Grafana for
monitoring. The primary outcome was the establishment of an automated, reliable, and efficient
process for application builds, testing, and deployments, significantly improving the software delivery
lifecycle. The selection of this toolset reflects a strategy prioritizing stability and leveraging
established, widely adopted practices, particularly common in Java application environments
indicated by the use of Maven.

2. Technology Stack and Roles

The project integrated several key DevOps tools, each serving a specific function within the build,
deployment, and monitoring workflow. The synergy between these tools enabled end-to-end
automation.

 Git: Served as the distributed version control system, managing all source code changes. It
facilitated collaboration among developers and acted as the trigger for initiating the CI/CD
pipeline upon code commits or merges.

 Maven: Employed as the build automation tool specifically for the Java-based medical
application. Its responsibilities included compiling source code, managing project
dependencies automatically, and executing unit tests to ensure code quality.

 Jenkins: Acted as the central automation server, orchestrating the entire CI/CD pipeline. It
automated the sequence of steps including code checkout, building, testing, container image
creation, and triggering deployment.

 Docker: Utilized for containerizing the application. It packaged the compiled application
artifact (JAR/WAR file) along with its Java runtime environment and dependencies into a
lightweight, portable container image, ensuring consistency across development, testing,
and production environments.

 Ansible: Functioned as the deployment automation tool. Triggered by Jenkins, Ansible

playbooks managed the deployment of the Docker container to the target server
infrastructure, handling configuration tasks as needed.

 Grafana: Provided monitoring and visualization capabilities for the deployed application. It
allowed the team to observe application performance, system health, and resource
utilization through customizable dashboards.
The combination of Jenkins for orchestration, Docker for consistent packaging, and Ansible for
deployment automation established a clear separation of concerns. Jenkins managed the workflow,
Docker ensured the application artifact was self-contained and environment-agnostic, and Ansible
handled the specifics of placing and running that artifact on the target infrastructure. This modular
approach enhances maintainability and leverages each tool's strengths effectively.

The following table summarizes the primary role of each tool within this project:

Tool Primary Role in Project

Git Version Control & CI Trigger

Maven Java Build, Dependency Mgmt, Test

Jenkins CI/CD Pipeline Orchestration

Docker Application Containerization

Ansible Deployment Automation

Grafana Application Monitoring

3. Development and Build Process

The development process adhered to modern version control practices using Git, specifically
adopting a workflow similar to the Feature Branch Workflow. Developers worked on new features or
bug fixes in dedicated, isolated branches created from the main codebase (main or develop). This
encapsulation prevented unstable code from disrupting the primary development line and allowed
multiple developers to work concurrently without interference. Before changes were integrated into
the main branch, they underwent code review via pull requests, fostering collaboration and
maintaining code quality.

Upon successful merging of a feature branch into the main branch (or sometimes on commit to a
feature branch), the automated build process was triggered within Jenkins. Jenkins invoked Maven to
manage the build lifecycle of the Java application. Maven executed a sequence of standard phases:

1. validate: Ensured the project structure was correct and necessary information was available.

2. compile: Compiled the Java source code into bytecode.

3. test: Executed automated unit tests against the compiled code using a suitable framework
(like JUnit or TestNG), providing immediate feedback on code correctness.

4. package: Bundled the compiled code and resources into a distributable format, typically a
JAR or WAR file for this web application.

Maven also automatically managed project dependencies, downloading required libraries from
repositories, simplifying dependency management across the team. The adoption of the Feature
Branch Workflow directly supported the Continuous Integration practice. Isolating changes in
branches minimized integration conflicts, and the pull request mechanism provided a natural point
to trigger automated builds and tests via Jenkins and Maven. This allowed for frequent validation of
code changes, catching errors early in the development cycle, which is a core principle of CI.

4. CI/CD Pipeline Implementation (Jenkins & Docker)

The Jenkins server orchestrated the CI/CD pipeline, automating the workflow from code commit to a
deployable artifact. The pipeline, typically defined as code (e.g., using a Jenkinsfile), consisted of
several distinct stages triggered automatically after code integration in Git:

1. Checkout: Jenkins pulled the latest source code from the designated branch in the Git
repository.

2. Build & Test: Jenkins executed Maven commands (e.g., mvn clean package or mvn clean
install) to compile the source code, run unit tests, and package the application into a JAR or
WAR file. A successful outcome in this stage indicated the code was syntactically correct and
passed basic functional checks.

3. Docker Build: Using instructions defined in a Dockerfile, Jenkins built a Docker image. This
process involved:

o Starting from a base image containing the necessary Java Runtime Environment (e.g.,
openjdk:17-alpine).

o Copying the application artifact (the JAR/WAR file created by Maven) into the
image's filesystem.

o Setting the working directory and defining the command to run the application when
a container starts (java -jar...).

4. Docker Push (Implied): The newly built Docker image was likely tagged with a version
identifier and pushed to a central container registry (e.g., Docker Hub, Nexus, AWS ECR). This
registry acts as a repository for storing and distributing images.

5. Deploy Trigger: Upon successful completion of the previous stages, Jenkins triggered the
deployment process managed by Ansible.

Docker played a critical role by encapsulating the application and all its dependencies within the
container image. This ensured that the application ran in a consistent and predictable environment,
regardless of where the container was deployed, effectively eliminating the "it works on my
machine" problem. Building the Docker image as an integral part of the automated Jenkins pipeline
guaranteed that the containerized artifact precisely matched the version-controlled code that had
just passed the build and test stages. This created a verifiable and traceable link from code commit to
the final deployable unit, enhancing reliability and auditability.

5. Deployment Automation (Ansible)

Ansible was responsible for automating the deployment of the containerized medical application to
the target environments (e.g., staging or production servers). Following a successful CI pipeline run in
Jenkins, Jenkins invoked Ansible, passing necessary parameters like the specific Docker image tag to
deploy.

Ansible executed predefined tasks outlined in YAML-based playbooks. For this project, the
deployment playbook likely included tasks such as:

 Ensuring the Docker engine was installed and running on the target host(s).

 Authenticating with the container registry and pulling the specified version of the
application's Docker image.
  Stopping and removing any existing container running the previous version of the application
to prepare for the update.

 Starting a new container based on the newly pulled image, configuring necessary parameters
like network port mappings (e.g., mapping port 8080 on the host to the application's port
inside the container) and potentially mounting data volumes.

By defining the deployment process as code within Ansible playbooks, the project achieved
repeatable and consistent deployments. This Infrastructure-as-Code (IaC) approach minimizes
manual errors and configuration drift between environments. Using Ansible standardized the
deployment mechanism across different stages (like testing, staging, production). The same
playbook, potentially parameterized with environment-specific variables (like database credentials or
API endpoints), could be reused, ensuring that the deployment process itself was consistent,
complementing the application-level consistency provided by Docker. This consistency is particularly
vital for medical applications where operational reliability is paramount.

6. Monitoring and Visibility (Grafana)

Post-deployment, continuous monitoring of the medical platform application's health and

performance was established using Grafana. Grafana served as the central visualization platform,
providing crucial visibility into the running application and its underlying infrastructure.

Grafana was configured to connect to one or more data sources that collected relevant metrics.
While not explicitly listed in the initial requirements, a common setup involves using Prometheus to
scrape metrics from the application and infrastructure, with Grafana then querying Prometheus for
data visualization.

Dashboards were created within Grafana to display key performance indicators (KPIs) and
operational metrics in an easily digestible format. These dashboards likely included visualizations for:

 Application Performance: Metrics such as request latency (how long API calls take), request
throughput (number of requests per second), and error rates (percentage of failed requests).

 Resource Utilization: CPU and memory usage of the Docker container and potentially the
host machine, helping to identify resource bottlenecks or leaks.

 Java Virtual Machine (JVM) Metrics: Specific metrics related to the Java runtime, like heap
memory usage and garbage collection activity.

 Infrastructure Health: Basic host-level metrics like disk space and network I/O.

This monitoring setup enabled the team to proactively detect issues, troubleshoot problems faster,
and analyze performance trends over time. The integration of monitoring early in the process
established an essential feedback loop. Performance regressions or increased error rates observed in
Grafana dashboards immediately following a deployment could be quickly correlated with the
specific code changes. This information feeds directly back into the development process, potentially
triggering bug fixes tracked in Git and initiating new runs of the CI/CD pipeline via Jenkins, thus
transforming the pipeline from a simple deployment mechanism into a cycle of continuous
improvement.

7. Conclusion

The project successfully deployed the simple medical platform application by establishing a fully
automated CI/CD pipeline leveraging Git, Maven, Jenkins, Docker, Ansible, and Grafana. The
integration of these tools streamlined the entire software delivery process, from code commit to
production monitoring.

The key achievements include significantly increased deployment frequency, improved operational
reliability through automated testing and consistent environments, and enhanced visibility into
application performance. The use of Docker ensured application consistency, while Ansible provided
repeatable deployment automation. Git facilitated controlled code management and collaboration,
Maven ensured reliable builds for the Java application, Jenkins orchestrated the end-to-end
automation, and Grafana provided critical operational feedback. This implementation not only met
the immediate deployment goals but also established a robust foundation. The automated,
repeatable nature of the pipeline reduces the overhead and risk associated with future updates,
enabling the development team to deliver new features and improvements for the medical platform
more rapidly and safely, ultimately increasing the velocity of value delivery.