About
What this project is for, and what it deliberately gets wrong.
This is the deliverable for Task-03: a Java application whose build, test and deployment are automated end to end. The application itself is deliberately small, because the subject of the task is the machinery around it.
What the task asked for
| Objective | Where it is met |
|---|---|
| Automate Java project builds using Gradle | One command compiles, tests, reports and packages. The Gradle wrapper pins the build tool version inside the repository. |
| Manage dependencies efficiently | A central version catalogue, correct scopes per dependency, and lock files that pin resolved versions across machines. |
| Integrate CI/CD for continuous delivery | A Jenkins pipeline defined in the repository runs on every push and carries a passing commit all the way to a running service. |
| Streamline build and deployment | Releases unpack into timestamped directories behind a symlink, which makes both deploying and rolling back a single fast operation. |
| Understand core DevOps principles | Reproducible builds, fast feedback, versioned configuration, least privilege, and a service that restarts itself when it dies. |
The part worth arguing about
Running Jenkins on the same machine as the application is convenient for a single task and wrong for anything real. The build competes with the service for memory, and a compromised pipeline owns production directly. A separate build host, or a hosted runner deploying over SSH, is the honest arrangement.
Running it yourself
Clone the repository, then run ./gradlew run. The wrapper
fetches the correct Gradle version and the application starts on port 8080. No other
setup is required.