> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# APPENDIX B Pre Requisite CICD
> Beginner guide to Docker-based CI/CD pipelines for building, testing, and deploying reproducible containerized applications.
Hello and welcome to this lesson on CI/CD builds.
This prerequisite introduces CI/CD builds using Docker for beginners with no prior knowledge. If you already understand CI/CD concepts, feel free to skip this lesson and review how CI/CD applies to OpenShift instead.
Once your application is built and the source code is pushed to a repository, the next step is packaging it for distribution or execution so it can be consistently deployed across environments.
## Why packaging alone is often not enough
Packaging source code into distributable artifacts (JARs, wheels, gems, etc.) is necessary but not sufficient for reliable deployments. Operations teams or consumers still need to:
* Ensure the correct runtime (Java, Python, Ruby, etc.) is installed on the target host.
* Install and configure application dependencies.
* Adjust configuration files and system services.
* Start and monitor the application correctly.
Leaving these tasks to manual steps increases the risk of misconfiguration and inconsistent behavior across environments. Containerization solves these problems by bundling the runtime, dependencies, and configuration together.
## Common packaging examples
Below are common artifact types and the typical commands used to run or install them.
| Language | Typical Artifact | How to Run / Install | Notes |
| -: | - | - | - |
| Java | JAR, WAR, EAR | `java -jar app.jar` | WAR/EAR usually deployed to app servers (Tomcat, WildFly, WebLogic). |
| Python | sdist (`sdist`), wheel (`bdist_wheel`) | `pip install dist/app.tar.gz` or `pip install dist/app.whl` | Use `build` or setuptools to create artifacts. |
| Ruby | Gem | `gem install app.gem` | Gems package Ruby libraries/executables for distribution. |
## Move runtime and setup into a Docker image
To make execution reproducible and remove manual setup, move installation and configuration instructions into a Dockerfile. Building a Docker image packages the application with its runtime and all required dependencies, producing a single executable image that can run anywhere Docker (or a compatible container runtime) is available.
## Example packaging and run workflow
Use the native packaging commands during development or for local distribution. For consistent deployment across environments, create a Docker image:
```bash theme={null}
# Run the built application artifacts directly (development/test)
java -jar app.jar
pip install dist/app.tar.gz
gem install app.gem
# Build a Docker image from a Dockerfile (recommended for reproducible deployments)
docker build -t app:latest .
# Run the built Docker image
docker run --rm app:latest
```
## Testing the image before release
After building the Docker image, automate tests to validate behavior before releasing:
* Unit tests and integration tests should run against the build artifacts or within the image.
* Acceptance tests and end-to-end UI tests (e.g., Robot Framework, Selenium) can exercise the running container to verify end-to-end behavior.
* Include smoke tests in the CI pipeline to catch obvious runtime faults quickly.
Automated testing in the pipeline helps prevent broken images from reaching production.
## Releasing and deploying images
Once tests pass, push the Docker image to a registry (Docker Hub, a private registry, or a cloud registry). Deployment automation or consumers can then pull the image and deploy it to container hosts or orchestration platforms such as Kubernetes, OpenShift, or hosted container services.
## Build pipeline and automation
The typical CI/CD pipeline stages are:
* Source: Commit or merge code into a repository (Git).
* Build: Compile code, build artifacts (JAR, wheel, gem).
* Image: Create a Docker image using a Dockerfile that includes runtime and dependencies.
* Test: Run automated test suites against the image and running containers.
* Release: Push approved images to a Docker registry.
* Deploy: Deploy images to orchestration platforms (Kubernetes/OpenShift) or other hosting environments.
These steps can be automated with CI/CD systems like Jenkins, Bamboo, GitHub Actions, GitLab CI/CD, and others to run on commits or pull requests.
Useful references:
* [Jenkins](https://learn.kodekloud.com/user/courses/jenkins)
* [GitHub Actions](https://learn.kodekloud.com/user/courses/github-actions)
* [GitLab CI/CD](https://learn.kodekloud.com/user/courses/gitlab-ci-cd-architecting-deploying-and-optimizing-pipelines)
* [Kubernetes Documentation](https://kubernetes.io/docs/)
Use containers to encapsulate runtime, dependencies, and configuration so deployments are reproducible across environments and remove manual setup steps from operations.
This diagram illustrates a typical CI/CD flow: source code in a repository triggers a build server (Jenkins in the diagram), which builds artifacts and Docker images (using a Dockerfile), runs automated tests, pushes approved images to a Docker registry, and finally deploys the images to a container orchestration platform such as Kubernetes.
## Summary
* Packaging produces distributable artifacts (JARs, wheels, gems), but does not guarantee reproducible deployments.
* Building Docker images encapsulates runtime, dependencies, and configuration for consistent execution anywhere containers run.
* Automate the pipeline (build → image → test → registry → deploy) with CI/CD tools to accelerate delivery and reduce manual errors.
Further reading and resources:
* [Docker Documentation](https://docs.docker.com/)
* [Kubernetes Basics](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.