✅ Continuous Integration (CI) Practices

1. Maintain a Code Repository

●​ Use a single source repository for all code and build artifacts.​

●​ The system must be buildable from a fresh checkout without requiring external
dependencies.​

●​ Mainline branch should always contain the working version.​

●​ Encourage integration of changes, not maintaining multiple software versions.​

2. Automate the Build

●​ Automate everything from compilation to deployment.​

●​ Include:​

○​ Binary builds​

○​ Documentation generation​

○​ Website/pages​

○​ Statistics​

○​ Distribution packages​

●​ Use build scripts to ensure consistency and reduce manual effort.​

3. Make the Build Self-Testing

●​ After building, automatically run all tests.​

●​ Ensures the system behaves as expected.​

●​ Detects integration and regression issues early.​

4. Everyone Commits to the Baseline Every Day

●​ Encourages frequent integration to reduce merge conflicts.​

●​ Avoids large, risky merges.​

●​ Keeps the codebase up-to-date and synchronized.​

5. Every Commit Should Be Built

●​ Each commit triggers a new build process.​

●​ Validates integration and identifies breaking changes early.​

6. Every Bug-Fix Commit Should Include a Test Case

●​ Add a test that reproduces the bug before the fix.​

●​ Prevents regressions and documents the issue.​

●​ Ensures the bug doesn’t return unnoticed in future versions.​

7. Keep the Build Fast

●​ Aim for rapid builds to reduce feedback time.​

●​ Faster builds = faster issue identification = higher productivity.​

8. Test in a Clone of the Production Environment

●​ Avoid discrepancies by using a production-like testing environment.​

●​ Use staging environments that mimic production:​

○​ Same OS​

○​ Same middleware (e.g., DB, web servers)​

 ○​ Scalable but cost-effective​

9. Make it Easy to Get the Latest Deliverables

●​ Provide easy access to builds for testers and stakeholders.​

●​ Enables early validation and feedback.​

●​ Developers should update their codebase daily.​

10. Everyone Can See the Results of the Latest Build

●​ Use dashboards or notifications to show:​

○​ Build status​

○​ Committer information​

○​ Change details​

●​ Encourages accountability and transparency.​

11. Automate Deployment

●​ Use scripts or tools (e.g., Jenkins, GitHub Actions) to:​

○​ Deploy to test servers​

○​ Enable continuous deployment (CD) to production​

●​ Automates rollback and validation processes.​

✅ CI/CD Principles and Team Responsibilities

1. Develop CI/CD Principles
 ●​ Goal: Enhance development efficiency and software delivery speed.​

●​ Principles are defined collaboratively by stakeholders.​

●​ Team acts as the authority on all things CI/CD:​

○​ Design and implement effective CI/CD processes.​

○​ Drive best practices across the organization.​

2. Review and Modify CI/CD Principles

●​ CI/CD is not static – regular review is essential.​

●​ Teams must:​

○​ Evaluate effectiveness of existing CI/CD practices.​

○​ Understand cross-team interactions and workflows.​

○​ Identify bottlenecks and suggest improvements.​

●​ Conduct iterative reviews to ensure:​

○​ Processes align with evolving business and technical needs.​

○​ Continuous optimization opportunities are surfaced.​

3. Manage CI/CD Tools & Platforms

●​ Once principles are defined, tools bring them to life.​

●​ CI/CD platforms enable:​

○​ Automation of pipelines​

○​ Execution of defined processes​

●​ Requires a blend of:​

○​ DevOps knowledge (focus on both Dev and Ops)​

 ○​ Architecture awareness (how systems interact)​

○​ Operational reliability (ensuring consistent uptime)​

4. Develop and Maintain Pipeline Configurations

●​ Core responsibility of CI/CD teams.​

●​ Pipelines vary depending on the tool (e.g., Jenkins, GitHub Actions, GitLab CI, CircleCI).​

●​ Tasks include:​

○​ Writing YAML/JSON or scripts for pipelines.​

○​ Managing build, test, security, and deployment stages.​

○​ Documenting pipelines so teams understand:​

■​ How their software is built​

■​ What tests are run​

■​ How it's deployed​

5. Automate Processes

●​ Automation is central to CI/CD success.​

●​ Responsibilities include:​

○​ Automating pipeline execution steps (build, test, deploy).​

○​ Ensuring inter-tool communication and third-party integrations.​

○​ Reducing manual intervention to speed up delivery and reduce errors.​

🛠️ Tools Typically Used

●​ CI/CD Platforms: Jenkins, GitHub Actions, GitLab CI/CD, CircleCI, Travis CI​
 ●​ Pipeline Configuration: YAML, JSON, Groovy (for Jenkins), Shell scripts​

●​ Supporting Tools: Docker, Kubernetes, Terraform, Ansible, SonarQube​

1. Organization User​
At the top of this architecture is the Organization User, the individual or team responsible for
making changes to the codebase. These changes trigger the Jenkins build process.

2. Source Code Repository​

The source code is managed in a Source Code Repository, typically using a version control
system (VCS) like Git. Jenkins is integrated with the repository through SCM (Source Code
Management), allowing it to monitor changes (commits or merges). Once a change is detected,
Jenkins pulls the latest version of the code to begin the build process.

3. Master Node (Controller)​

The Master Node, also known as the Controller, is the brain of the Jenkins architecture. It
schedules build jobs, monitors the agents (slave nodes), and assigns jobs based on predefined
rules. The master node doesn’t usually execute the build or test jobs but instead delegates
them to agents that are better suited for those tasks.

4. Slave Nodes (Agents)​

Jenkins can distribute workloads across various Slave Nodes (Agents). Each agent is a machine
(physical or virtual) that performs the actual work. In the diagram above, we have three
different types of agents:

●​ Agent1: A Windows-based machine that handles Windows-specific jobs.

●​ Agent2: A Linux-based machine for running jobs in Linux environments.
●​ Agent3: A MacOS machine, used when builds or tests require a Mac environment.

The communication between the master node and the agents is typically established via SSH or
JNLP.

5. Build, Test, Deploy​

Once the agents receive jobs from the master, they proceed with the Build, Test, and Deploy
stages:
 ●​ Build: The source code is compiled, and build artifacts are created.
●​ Test: Automated tests are run to ensure the build is stable and free of defects.
●​ Deploy: If the build and tests pass, the application can be deployed to staging or
production environments.

The ability to run jobs on different agents allows for greater flexibility and efficiency, especially
in large projects with varying platform requirements.

Build Process Steps

1.​ Code Checkout (Local Development)​
Developers check out code from the source control repository into their private
workspaces.​

2.​ Local Changes and Testing​

Developers make changes to the code and test them locally.​

3.​ Code Check-in (Commit)​

After successful local testing, developers check in (commit) their changes back to the
source control repository.​

4.​ CI Server Detection and Build Trigger​

The Continuous Integration (CI) server monitors the repository. When it detects new
changes, it triggers a build of the relevant code.​

5.​ Post-Build Activities (if build is successful)​

The CI server may perform the following tasks:​

○​ Generate and make deployable artifacts available for testing.​

○​ Assign a build label (or version tag) to the current code.​

○​ Notify the development team of a successful build.​

○​ Trigger automated unit tests and integration tests.​

6.​ Build Labeling and Reproducibility​

The changes committed in step 3 are now part of a labeled build, allowing the same
build to be reproduced if needed.​

7.​ Build Failure Handling​

If the build fails, the CI server sends notifications to the developers responsible. They
then:​

○​ Review and fix the issues.​

 ○​ Restart the process from step 1.​

8.​ Testing Feedback​

After automated testing is complete, the CI server notifies the team members of the
test results.