The document outlines the roles, processes, and tools related to Continuous Integration (CI) and Continuous Deployment (CD) in various environments (development, QA, production). It details the responsibilities of different roles such as committer and deployer, as well as the purposes and management of artifact repositories across these environments. Separate repositories ensure security and compliance, with specific guidelines on building and deploying software through automated and manual testing processes.

1. CI / CD
Roles, Processes and Supporting Tools

2. Contents
• Roles
• Artifact Repositories
• General
• Instances
• Development
• QA
• Production
• CI / CD Overviews
• Development
• QA
• Production

3. Roles
Development Environment
• Committer-Development: Group members can branch and check in code
• Deployer-Development: Group members can deploy specified artifacts to specified targets in Acceptance
Generally, everyone with Development access has both roles in Development and only developers should have
the Committer-Development: role
QA Environment
• Committer-QA: Group members can check in configurations only
• Deployer-QA: Group members can deploy specified artifacts to specified targets in QA
Committer-Development members should never have either role in QA
Production Environment
• Deployer-Production: Group members can deploy specified artifacts to specified targets in Production
Committer-Development or Committer-QA members should never have the Deployer-Production role.

4. Artifact Repositories - General
Purpose
An artifact repository serves these essential purposes:
• Securely store binary and related metadata for deployable code
• Provide auditability on Release Management and Change Control
code used for deployments

5. Artifact Repositories - Instances
• Often there are three distinct logical, and very often physical,
instances of artifact repositories: “Development”, “QA”, and
“Production”
• Separated logical or physical repositories ensure segregation of
duties, auditability, traceability, and reduced opportunities for errors.
• The artifacts stored in the repositories are either different builds
(Development vs QA) or have different levels of QA certification (QA
vs Production)
• Security often requires separate instances due to network
segmentation and NACLs for non-Production and Production.

6. Artifact Repositories - Development
Development
• This artifact repository holds “Snapshot” builds that are kicked off
from Developers’ check-ins to Source Control
• All automated tests are run on these builds
• These builds happen frequently (often many times a day per active
developer) and only need to be kept for a short period (days/weeks)
• Snapshot builds are never deployed to QA nor Production

7. Artifact Repositories - QA
QA
• This artifact repository holds “Release Candidate” builds.
• These builds are usually kicked off manually upon request when a build is
promoted out of Development to be tested for Production readiness.
• All automated tests are run on these builds.
• Additional manual and other tests are run on these builds (e.g. end-to-end,
additional security, Performance Engineering, etc.).
• “Release Candidate” builds happen less frequently than development
builds and, after the initial build, often to resolve issues found during QA.
• Builds are kept for a “medium” length of time, generally until a Release
Candidate build gets a “QA Pass”; failed builds are removed frequently.

8. Artifact Repositories - Production
Production
• This artifact repository holds QA Passed “Release” builds.
• Only Release Candidate builds can be promoted to Release Builds. Never
should new builds be made for production that have not been QA tested
and passed.
• Environment specific configuration values must be parameterized and
externalized to the build artifact (as per “12 Factor App” guidelines).
• Production deployments and rollbacks are only allowed from artifacts in
the Production Repository.
• There should be a relatively small number of Release builds. These builds
are kept indefinitely or as per corporate policy.

9. CI / CD: Development
1. Developer checks
in code
2. CI process
started
automatically
3. Snapshot builds put
into repository
3. Code deployed
to target
1. Build version and
target selected in UI
2. Artifact retrieved from repository
CI Process
CD Process
Deployer-Development
Committer-Development
Development
instance
Development
instance

10. CI / CD: QA
1. QA or other checks
in configurations only
2. CI process
started
3. Release builds put
into repository
3. Code deployed
to target
1. Build version and
target selected
2. Artifact retrieved from repository
CI Process
CD Process
Deployer-QA
Committer-QA
QA/Prod
instance
QA/Prod
instance

11. CI / CD: Production
3. Code deployed
to target
1. Build version and
target selected
2. Artifact retrieved from repository
CD Process
Deployer-Production
QA/Prod
instance