Agile & CI/CD
Agile development is an iterative and incremental approach that prioritizes flexibility, collaboration, and customer feedback. It enables faster and more adaptive delivery of high-quality software compared to traditional, rigid methods like Waterfall.
Instead of trying to deliver the entire software product at once, Agile teams break the work down into small, manageable development cycles called sprints (typically lasting 1-4 weeks). Each sprint produces a working and potentially releasable increment of the product.
The Agile Manifesto
Section titled “The Agile Manifesto”Agile is rooted in a set of values and principles published in the Agile Manifesto (2001). It prioritizes:
| We value… | Over… |
|---|---|
| Individuals and interactions | Processes and tools |
| Working software | Comprehensive documentation |
| Customer collaboration | Contract negotiation |
| Responding to change | Following a plan |
Key Agile Principles
Section titled “Key Agile Principles”The manifesto is backed by 12 principles. The most important in practice:
- Deliver working software frequently - from a couple of weeks to months, with preference for the shorter timescale.
- Welcome changing requirements, even late in development.
- Business people and developers must work together daily.
- Build projects around motivated individuals; trust them to get the job done.
- The best architectures emerge from self-organizing teams.
- Reflect regularly on how to become more effective, then adjust behavior.
Scrum Framework
Section titled “Scrum Framework”Scrum is the most widely adopted Agile framework. It organizes work into fixed-length sprints and prescribes specific roles, ceremonies, and artifacts.
| Role | Responsibility |
|---|---|
| Product Owner (PO) | Owns the Product Backlog. Prioritizes features based on business value. The single voice of the customer/stakeholder to the team. |
| Scrum Master (SM) | Facilitates the Scrum process. Removes impediments. Coaches the team on Agile practices. Not a project manager. |
| Development Team | Cross-functional, self-organizing group that builds the product increment each sprint. Typically 3–9 people. |
Ceremonies (Events)
Section titled “Ceremonies (Events)”| Ceremony | When | Purpose |
|---|---|---|
| Sprint Planning | Start of each sprint | Team selects items from the Product Backlog and plans how to deliver them. |
| Daily Standup | Every day (~15 min) | Each member answers: What did I do? What will I do? Any blockers? |
| Sprint Review | End of sprint | Team demos the increment to stakeholders and gathers feedback. |
| Sprint Retrospective | After Sprint Review | Team inspects its process and identifies improvements for the next sprint. |
Artifacts
Section titled “Artifacts”- Product Backlog: An ordered list of everything that might be needed in the product - features, bug fixes, and technical improvements. Maintained and prioritized by the Product Owner.
- Sprint Backlog: The subset of Product Backlog items selected for the current sprint, plus a plan for delivering them.
- Increment: The sum of all completed Product Backlog items at the end of a sprint. It must be usable and meet the team’s Definition of Done.
Kanban
Section titled “Kanban”Kanban is a flow-based Agile framework focused on visualizing work and limiting work-in-progress (WIP). Unlike Scrum, Kanban has no fixed sprints - work items flow through the board continuously.
Core Principles
Section titled “Core Principles”- Visualize the workflow: Use a Kanban board with columns representing each stage (e.g., Backlog → In Progress → Review → Done).
- Limit Work-in-Progress (WIP): Each column has a maximum number of items allowed at once. This exposes bottlenecks and keeps flow smooth.
- Manage flow: Monitor cycle time (how long items take) and optimize the system.
- Continuous improvement: Teams regularly analyze the board and identify process improvements.
Scrum vs. Kanban
Section titled “Scrum vs. Kanban”| Aspect | Scrum | Kanban |
|---|---|---|
| Cadence | Fixed sprints (1–4 weeks) | Continuous flow |
| Roles | PO, SM, Dev Team | No prescribed roles |
| WIP Limits | Implicit (sprint scope) | Explicit per-column limits |
| Change Policy | No changes mid-sprint | Changes accepted anytime |
| Best For | Product development with recurring releases | Support, ops, or continuous delivery |
The CI/CD Pipeline
Section titled “The CI/CD Pipeline”Agile methodologies perfectly complement modern DevOps practices - specifically the Continuous Integration / Continuous Delivery (CI/CD) pipeline. A CI/CD pipeline automates the steps required to get code from a developer’s machine into production safely and quickly.
Continuous Integration (CI)
Section titled “Continuous Integration (CI)”Developers regularly integrate their code changes into a shared central repository (like GitHub or GitLab), often multiple times a day.
- Every commit triggers an automated build and testing sequence.
- Goal: Verify seamless integration and detect merge conflicts or code issues as early as possible.
Continuous Testing (CT)
Section titled “Continuous Testing (CT)”Automated tests (unit, integration, and security scans) are executed automatically throughout the software development lifecycle.
- Identifies bugs, vulnerabilities, and defects early.
- Acts as the quality gate preventing bad code from moving forward in the pipeline.
Continuous Delivery / Deployment (CD)
Section titled “Continuous Delivery / Deployment (CD)”Enables rapid and reliable software releases by automatically deploying code changes that pass the CI and CT stages.
- Continuous Delivery: Automates the pipeline up to the staging environment. A human must manually approve the push to production.
- Continuous Deployment: Automates the entire process. Any code that passes all automated tests is automatically deployed directly to production without human intervention.
GitOps
Section titled “GitOps”GitOps is a CD pattern where Git is the single source of truth for both application code and infrastructure state. Instead of a pipeline pushing changes to an environment, an operator running in the cluster (like ArgoCD or Flux) continuously pulls from Git and reconciles the live state to match.
| Aspect | Traditional CD | GitOps |
|---|---|---|
| Trigger | Pipeline pushes on merge | Operator pulls continuously |
| State source of truth | Pipeline config / scripts | Git repo |
| Rollback | Re-trigger pipeline | git revert |
| Drift detection | Manual / none | Automatic (operator alerts on drift) |
- Why it matters: In GitOps, your cluster state is always auditable via
git log. Unauthorized manual changes to the cluster get overwritten by the next reconciliation loop — the cluster self-heals toward what Git says it should be. - Typical stack: ArgoCD or Flux watching a Helm chart repo or kustomize directory, applying changes as PRs are merged.
Popular CI/CD Tools
Section titled “Popular CI/CD Tools”| Tool | Type | Key Feature |
|---|---|---|
| GitHub Actions | Cloud-native | Tightly integrated with GitHub repos; YAML-based workflows |
| GitLab CI/CD | Cloud / Self-hosted | Built-in to GitLab; powerful pipeline visualization |
| Jenkins | Self-hosted | Highly extensible open-source; massive plugin ecosystem |
| CircleCI | Cloud-native | Fast pipelines with strong parallelism support |
| ArgoCD | GitOps / Kubernetes | Declarative continuous delivery for Kubernetes clusters |