Continuous Integration & Continuous Delivery (CI/CD).

Context & Purpose

1  Purpose of the Document

The purpose of this document is to establish a standardized and scalable approach to Continuous Integration (CI) and Continuous Delivery (CD) at Memorres Digital Private Ltd. It defines the guiding principles, roles, tools, and practices that govern how software is built, tested, and deployed across all projects and environments.

2 This guide serves to:

• Ensure consistent and reliable software delivery pipelines.
• Minimize human error by automating repetitive and manual tasks.
• Promote faster feedback and shorter development cycles.
• Improve code quality through automated testing and enforcement of coding standards.
• Establish clear workflows for deploying to staging and production environments.
• Enable teams to onboard new services with minimal overhead by following pre-approved CI/CD templates.
• Enhance collaboration between development, QA, DevOps through a shared framework.
  

3 Why is it important?

CI/CD is a core component of modern DevOps culture. It enables:

• Faster delivery of features and bug fixes to users
• Lower risk through automation and frequent deployments
• Improved quality via standardized testing and validation
• Increased visibility and traceability of code changes
• Developer productivity by reducing manual handoffs

By establishing a unified CI/CD framework, we ensure that:

• All teams follow consistent, auditable, and secure deployment processes
• Pipelines are scalable, reusable, and easily maintainable
• New projects and services can be onboarded quickly with minimal overhead.

Scope

1 Scope

This guide applies to all software projects, teams, and environments managed under Memorres engineering and DevOps practices. It defines the common structure, expectations, and tooling for implementing and maintaining CI/CD pipelines across the organization.

2 Applicable Teams

• Development Teams:
  • Responsible for writing and merging code that triggers CI pipelines.
• DevOps Team:
  • Responsible for designing, maintaining, and securing CI/CD infrastructure.
• QA & Testing Teams:
  • Responsible for ensuring test coverage and validating pipeline test outcomes.
• Release Managers:
  • Oversee deployment approvals and release governance.
• Security Team:
  • Ensure pipelines comply with internal security policies and compliance requirements.
    

3 Stages

Step	What happens
Code Build	The code gets compiled (e.g. Node.js, Java)
Automated Tests	Unit tests / integration tests are executed
Package / Artifact Creation	A Docker image or ZIP/JAR file is created
Deploy to Environment	Code is deployed to the Dev/Staging/Prod environment
Validation	Health checks / smoke tests are run
Rollback	If deployment fails, it is automatically rolled back
Notification	Success/failure updates are sent via Slack/email

4 Applicable Environments

The CI/CD practices apply across the following standard environments:

• Development (Dev)
• Quality Assurance (QA)
• Staging (UAT)
• Production (Prod)
• Hotfix / Patch environments (if applicable)

5 Out of Scope

Projects or systems that are currently excluded:

• Legacy applications with no CI/CD compatibility
• Applications or infrastructure fully managed by external clients
• Ad hoc/manual deployments that are yet to be migrated to pipeline-based systems

This role allows both individual capability growth and long-term contribution toward platform stability, reusability, and delivery scalability.

Definitions & Abbreviations

This section defines key terms and abbreviations used throughout the document to ensure consistent understanding across all readers.

Term / Abbreviation	Definition
CI	Continuous Integration – practice of merging code changes frequently and automatically building/testing them.
CD	Continuous Deployment/Delivery – automatically deploying code to staging/production environments after successful testing.
SSM	AWS Systems Manager – used here mainly for Parameter Store to store and retrieve configuration values securely.
S3	Amazon Simple Storage Service – used for storing static assets, build artifacts, or environment files.
VPC	Virtual Private Cloud – an isolated cloud network where services like ECS and RDS operate securely.
RDS	Relational Database Service – managed database services (e.g., PostgreSQL, MySQL).
ECS	Elastic Container Service – used to deploy and manage Docker containers on AWS.
Docker	A platform for developing, shipping, and running applications in containers.
Pipeline	A defined set of CI/CD stages that build, test, and deploy code automatically.
Environment	A logical space where the application runs (e.g., dev, stg, prod, mvp).
POC	Proof of Concept – an experimental environment used to validate a new idea or feature.
MVP	Minimum Viable Product – a basic version of a product with just enough features for release.
DevOps	A set of practices that combine software development (Dev) and IT operations (Ops).
New Relic	A monitoring and observability platform used to track application and infrastructure performance.
Jenkins	An open-source automation server used to build and deploy code via pipelines.

Roles & Responsibilities

Step	What happens
Development Team	– Write and maintain application code- Configure application-specific CI/CD requirements (ex: special build scripts, environment variables, etc.)- Write and maintain unit tests and basic deployment configurations- Raise requests for onboarding new projects into the CI/CD system
DevOps Team	– Design, implement, and maintain the CI/CD pipeline framework- Provide reusable pipeline templates and shared scripts- Manage credentials and secret handling- Ensure security and compliance across pipelines- Collaborate with developers for environment-specific needs
QA Team	– Configure and maintain test automation integration- Validate QA stages in the pipeline- Review test results and raise issues- Collaborate with DevOps to ensure appropriate test gates
Project Manager/ Release Manager	– Plan sprint deliverables with CI/CD readiness in mind- Ensure coordination between Dev, QA, and DevOps teams- Track CI/CD adoption across projects- Raise support requests for CI/CD feature updates as needed
Security Team	– Review pipeline configurations from a security standpoint- Approve secrets handling and third-party integrations- Monitor for vulnerabilities in build dependencies and container images

CI/CD Process Overview

The CI/CD process ensures that code changes are integrated, tested, and deployed consistently and reliably. The process is broken down into the following stages:

1 Code Commit

• Developers push code changes to a version control system (e.g., GitHub).
• Each push triggers the pipeline automatically based on predefined triggers.

2 Build Stage

• Code is compiled or containerized, depending on the application type.
• Build artifacts (e.g., JAR files, static-content files, Docker images) are generated.
• Version tagging is applied based on commit or release strategy.

3 Test Stage

• Unit tests and integration tests are executed.
• Static code analysis and linting tools are run.
• Code coverage and quality gates are evaluated.
• If any of the tests fail, the pipeline stops here.

4 Artifact Storage

• Successful build artifacts are uploaded to artifact repositories like:
  • Docker images → Amazon ECR
  • Build files → S3 or GitHub Releases
• Artifacts are tagged with environment-specific versions (e.g., dev, stg, prod).

5 Staging Deployment

• Deploys to a staging environment using pipeline templates.
• Application runs in a production-like environment for further validation.
• QA team performs manual or automated testing.

6 Approval Gate

• Developers push code changes to a version control system (e.g., GitHub).
• Developer get approval from the team lead to move ahead with the deployment.
• Developer triggers the pipeline using the Jenkins UI.

7 Production Deployment

• Code is deployed to the production environment.
• Health checks, monitoring, and alerting are automatically activated.
• Post-deployment validation is performed.

8 Rollback Strategy

• Rollback procedures are built into the pipeline using:
  • Previous stable images
  • Infra templates to revert config changes
• Alerts notify stakeholders in case of failed deployment.

Standards & Best Practices

This section outlines the technical and procedural standards that guide the CI/CD pipelines across all projects. Adhering to these practices ensures consistency, security, maintainability, and operational excellence throughout the software development lifecycle.

1 Source Code Management

• All source code must be version-controlled using Git, preferably hosted on GitHub under organizational accounts.
• Branching strategy should follow Git Flow, clearly defined per project.
• All changes must be committed with descriptive messages and associated with ticket references (e.g., JIRA ID).

2 Branching & Merging Standards

• Protected branches must be used for main and release branches.
• Code merges to protected branches must happen through Pull/Merge Requests.
• Reviews and approvals (minimum 1 or 2 approvers) are mandatory for every Pull/Merge Request.
• Feature branches should follow naming conventions like feature/, bugfix/, hotfix/.

3 Build Standards

• Builds should be reproducible and consistent across environments.
• Use environment-specific configuration files or secrets management tools (e.g., AWS SSM).
• The build system should enforce linting, static code analysis, and unit testing.

4 Test Automation

• Unit tests are mandatory for all critical application logic.
• Integration tests should run post-build but pre-deployment to any environment.
• End-to-End (E2E) tests are required for staging and production environments.
• Testing frameworks must be standardized per language/team.

5 Deployment Standards

• Use blue/green or rolling deployments where applicable.
• All deployments must be triggered via CI/CD pipelines; manual deployments must be logged and justified.
• Ensure proper rollback mechanisms are in place for each environment.

6 Secret Management

• No secrets should be stored in code repositories.
• Use secure secrets managers (e.g., AWS SSM parameter store, AWS Secrets Manager).
• Access to secrets must be governed by the principle of least privilege.

7 Logging & Monitoring Standards

• Pipelines should emit logs in a centralized logging platform (e.g., CloudWatch).
• All failed stages must provide meaningful logs for debugging.
• Include alerts for pipeline failures, test failures, and deployment issues.

8 Security Practices

• Static Application Security Testing (SAST) and Software Composition Analysis (SCA) should be integrated into pipelines(using tools like SonarQube and OWASP Dependency check, Synk).
• Perform vulnerability scanning on all container images (using tools like Trivy and AWS ECR Image scanning).
• Limit IAM permissions for deployment roles to the minimum necessary.

9 Documentation Standards

• Each pipeline must have up-to-date documentation.
• Include onboarding instructions, environment-specific behavior, and rollback procedures.
• Pipeline definitions should be versioned alongside the application.

Security & Compliance

1 Objective

Ensure that security and compliance considerations are integrated into every stage of the CI/CD lifecycle to protect source code, and deployment environments.

2 Key Security Measures

• Source Code Protection
  • Role-based access controls to repositories.
  • Enforced pull request reviews and branch protections in GitHub.
  • Secrets are stored in secure vaults (e.g., AWS SSM Parameter Store or Secrets Manager).
• Credential Management
  • No hardcoded credentials.
  • Use Jenkins Credentials Plugin to inject secrets into jobs securely.
  • Expired or rotated secrets must be updated regularly.
• Build Environment Security
  • Jenkins agents run with minimal privileges.
  • Jenkins access granted as per RBAC.
  • Jobs use isolated environments (e.g., Docker) wherever possible.
• Artifact Integrity
  • Artifacts are scanned for vulnerabilities using tools like Trivy or AWS Inspector.(not done by us currently)
  • Artifacts are digitally signed or checksummed.
  • Use S3 buckets or artifact repositories (e.g., ECR) with version control.
• Audit & Traceability
  • Jenkins logs are centralized and stored in CloudWatch.
  • Access to Jenkins is logged and monitored.
  • Git commits and build numbers are traceable to deployments.

3 Compliance Controls

• Pipeline Approval Gates
  • Manual approval required before deploying to staging and production.
  • Approval steps are defined in Jenkins using “Input” steps.
• Environment Isolation
  • Separate AWS accounts or environments for dev, staging, and prod.
  • Network-level segregation enforced via VPCs and Security Groups.

Tools & Technologies

This section outlines the core tools and technologies used to implement and maintain our CI/CD pipelines. The choice of tools is based on their integration capabilities, reliability, community support, and alignment with organizational needs.

1 Version Control System (VCS)

Tool	Purpose
Git (GitHub)	Manages source code, tracks changes, and facilitates collaboration across teams.

2 CI/CD Orchestration

Tool	Purpose
Jenkins	Automates build, test, and deployment workflows. Provides flexibility for managing complex pipelines and integrations.

3 Containerization & Orchestration

Tool	Purpose
Docker	Packages applications and dependencies into isolated containers for consistency across environments.
Amazon ECS	Orchestrates container deployment, scaling, and lifecycle management.

4 Artifact Repositories

Tool	Purpose
AWS ECR	Stores and manages Docker images, libraries, and deployment packages.

5 Deployment Targets

Tool	Purpose
Amazon ECS / EC2 / Lambda	Targets for deploying applications depending on the workload type.
S3 (Static sites)	Hosts frontend applications or static websites.

6 Monitoring & Alerts

Tool	Purpose
CloudWatch / Prometheus / Grafana / New Relic	Monitors system health, logs, and metrics. Alerts on critical failures or threshold breaches.

7 Security & Compliance

Tool	Purpose
SonarQube	Performs code quality checks and static code analysis.
Trivy / AWS Inspector	Scans Docker images or infrastructure for vulnerabilities.
IAM / SSM Parameter Store / Secrets Manager	Manages credentials and environment variables securely.

Governance & Compliance

1 Purpose

This section outlines the governance and compliance framework associated with CI/CD processes. It ensures that development and deployment practices align with internal policies, industry standards, and regulatory requirements.

2 Governance Model

To maintain accountability and consistency, the governance model includes the following key areas:

• Approval Gates
  • Defined points in the CI/CD pipeline where approvals are mandatory (e.g., prior to production deployment).

• Change Management
  • All production deployments must be tracked via ticketing systems such as Jira or ServiceNow.

• Code Review Policies
  • Mandatory code reviews before merge/push to mainline branches. At least one peer reviewer and one senior engineer approval required.

• Branching Strategy Governance
  • Teams must adopt an approved branching strategy (e.g., GitFlow, trunk-based) to ensure streamlined release management.

• Pipeline Ownership
  • Clear ownership of pipelines must be established, ensuring accountability and maintenance responsibilities.

3 Compliance Requirements

All CI/CD workflows must adhere to the following compliance regulations and internal policies:

• Security Scanning
  • All code and container images must pass automated security scans (e.g., SAST, DAST, dependency scanning).

• Audit Trails
  • Every build and deployment must generate logs for auditing, including commit hashes, approvers, artifacts, and environments.

• Access Control
  • Least privilege principle enforced for access to pipelines, repositories, and deployment targets.

• Data Handling Compliance
  • Sensitive data (e.g., secrets, keys) must be managed via approved secret management systems (e.g., AWS Parameter Store, Vault) and never hardcoded or logged.

• Third-party Dependencies
  • Only approved and licensed third-party packages are allowed. Teams must document any usage of external libraries.

4 Internal Audits & Reviews

• CI/CD processes are subject to quarterly internal audits.
• Gaps identified must be addressed within the remediation window (e.g., 2 weeks for critical issues).

5 Policy Violations & Escalation

• Violations of CI/CD policies will be logged.
• Depending on severity, incidents may be escalated to team leads, DevOps heads, or compliance officers.