1. Commit
- Trunk-based or short-lived branches
- Gate: required review and passing pre-merge checks
CI/CD pipeline services
DevOps CI/CD pipeline services
A pipeline that is slow, flaky or skipped for hotfixes stops protecting production. Agnotic Technologies designs and builds CI/CD pipelines that build once, gate every stage, promote one signed artifact and deploy with a strategy you can roll back, on GitHub Actions, GitLab CI/CD, Azure Pipelines or AWS.
Build once, promoteA gate at every stageKeyless deploysRollback ready
Trusted by global innovators
CI/CD pipelines
What do DevOps CI/CD services include?
DevOps CI/CD services design, build and maintain the automated path from a code commit to a verified production release. Agnotic Technologies sets the pipeline stages and quality gates, picks a deployment strategy per application, removes stored cloud keys through OIDC federation and promotes one signed artifact through every environment, on the CI/CD platform your team already uses.
We build new pipelines and repair existing ones that have grown slow, depend on one engineer or get bypassed when production is on fire.
Test framework choice, security scanner tuning and Terraform each have their own pages. This one covers the pipeline that connects them.
Reference pipeline
What does a reference CI/CD pipeline look like?
Eight stages, each with a gate that must pass before the next one starts. The gates are what make the pipeline worth trusting.
2. Build once
- One build per commit with cached dependencies
- Gate: a reproducible build from a pinned toolchain
3. Test
- Unit, contract and integration suites in parallel
- Gate: every required suite green, nothing skipped
4. Scan
- Code, dependency, secret and image scans
- Gate: no new findings above the agreed severity
5. Package and sign
- A container image or bundle identified by its digest
- Gate: signature and provenance attached
6. Promote
- The same artifact moves from staging to production
- Gate: approval or automated checks per environment
7. Deploy
- Rolling, blue-green, canary or feature flag
- Gate: health checks during the traffic shift
8. Verify
- Smoke tests and an error-rate watch after release
- Gate: automatic rollback when checks fail
Decision table
Which deployment strategy fits each application?
The strategy decides how fast you can release and how fast you can undo a bad release. We choose it per application, not once for the whole company.
| Strategy | Fits when | Needs from the platform | Rollback path | Database changes |
|---|---|---|---|---|
| Rolling | Stateless services with several instances and clients that tolerate mixed versions | An orchestrator or instance group that replaces instances in batches | Redeploy the previous version batch by batch | Old and new code must both work with the schema during the roll |
| Blue-green | Releases that should switch all at once, with a quick way back | Two full environments and a load balancer or DNS switch | Point traffic back at the old environment | Expand the schema before the switch; contract only after the old environment is retired |
| Canary | Busy services where a small slice of traffic can expose a bad release | Weighted traffic routing and metrics per version | Shift the canary's traffic back to the stable version | Both versions share one schema for the whole canary period |
| Feature flag | Changes that should ship dark and turn on for chosen users later | A flag service and code paths for both states | Turn the flag off without a deploy | Write both shapes until the flag is fully on, then remove the old path |
Most products mix strategies, for example a canary for the public API, blue-green for a batch worker and feature flags for user-facing changes.
How do database schema changes ship without downtime?
Database schema changes ship without downtime through expand and contract: add the new structure first, move the code, then remove the old structure in a later release. The pipeline runs each step as its own migration, so no release depends on a schema that only some running versions understand.
Expand adds columns, tables or indexes that existing code ignores. The next release writes to both the old and new shapes and backfills older rows in batches.
Contract removes the old column or table only after every running version reads the new one and the backfill is verified. We keep that release separate, so it can wait while a rollback is still possible.
Destructive migrations never run in the same deploy step as the application change. A failed deploy should never leave you restoring a database.
Build once, promote
How does one artifact move from build to production?
Rebuilding for each environment means production runs something nobody tested. We build once and promote the same artifact by its digest.
1.
Build and record provenance
A hosted build produces one image or bundle plus a signed record of the source commit, the builder and the inputs.
Build2.
Sign and store
The artifact is signed and pushed to a registry. Only signed digests can be deployed.
Sign3.
Promote by digest
Staging and production pull the same digest. Configuration changes per environment; the artifact does not.
Promote4.
Verify at deploy time
The deploy step checks the signature and provenance and refuses anything built outside the pipeline.
VerifyPlatforms
Which CI/CD platform fits your stack?
We build on the platform you already have unless there is a clear reason to move. These are the features we set up on each one.
GitHub Actions
- Reusable workflows
- Environments with required reviewers
- OIDC to AWS, Azure and Google Cloud
- Hosted or self-hosted runners
GitLab CI/CD
- Pipeline templates and includes
- Protected environments
- OIDC ID tokens for cloud access
- Group runners
Azure Pipelines
- YAML templates
- Environments with approvals and checks
- Workload identity federation
- Hosted or self-hosted agents
AWS CodePipeline, CodeBuild and CodeDeploy
- Pipelines defined as code
- CodeBuild for builds and tests
- Canary and linear traffic shifting
- IAM roles instead of access keys
Failure points
Why do pipelines stop being trusted?
The problems we find most often when we take over an existing pipeline.
Challenge
Builds take so long that engineers batch changes or merge without waiting.
Agnotic approach
Cache dependencies, split suites to run in parallel and run the tests a change affects before merge, with the full set on the main branch.
Challenge
Hotfixes go to production by hand when something breaks.
Agnotic approach
A fast lane through the same pipeline that skips optional stages but keeps the build, the signature and the deploy step.
Challenge
Staging and production have drifted apart, so a green staging run proves little.
Agnotic approach
Both environments created from the same infrastructure code, with the configuration differences listed and reviewed.
Challenge
Long-lived cloud keys sit in CI secrets and nobody knows who can use them.
Agnotic approach
OIDC federation with roles scoped to one repository, branch and environment, then the old keys deleted.
Challenge
Each environment gets its own build, so production runs an untested binary.
Agnotic approach
One artifact per commit, promoted by digest, with deploys that reject unsigned artifacts.
Challenge
Undoing a failed release needs someone to work out the steps under pressure.
Agnotic approach
Rollback written into the deployment strategy and rehearsed, with automatic rollback on failed health checks.
Scope and cost
What drives the cost of DevOps CI/CD services?
We do not publish prices. These are the factors we size on the scoping call.
Services and repositories
Each one needs a pipeline, though shared templates keep that work small after the first.
Current pipeline state
A new pipeline is design and build; an existing one adds an audit and a migration that cannot stop releases.
Deployment targets
Kubernetes, virtual machines, serverless functions and app stores each need their own deploy and rollback steps.
Test suite health
Slow or flaky suites must be fixed before they can act as gates.
Environments and approvals
More environments and sign-offs mean more promotion rules and more release records.
Platform change
Moving from one CI/CD platform to another adds a period with both running.
Which teams ask us for CI/CD pipeline work?
Startups still releasing by hand
DevOps CI/CD services for startups usually begin with one pipeline template, preview environments and a single production deploy path.
Teams running on AWS
AWS CI/CD pipeline services built on CodePipeline, CodeBuild and CodeDeploy, or GitHub Actions deploying into AWS through OIDC roles.
Products with many services
Shared pipeline templates, so every service gets the same gates without copied YAML.
Regulated products
Approvals, signed artifacts and release records kept as evidence. Audit-ready release records for healthcare have their own page.
Teams changing CI platforms
A move from an older CI server to a hosted platform, one service at a time.
Facts and sources
Facts behind CI/CD pipeline design
Guidance from NIST, the SLSA specification and vendor documentation that shapes the gates and deploy steps on this page.
NIST SP 800-204D, published in February 2024, sets out strategies for integrating software supply chain security into DevSecOps CI/CD pipelines.
Source: NIST SP 800-204DIn the SLSA Build track, Build L1 requires provenance showing how a package was built, Build L2 requires signed provenance generated by a hosted build platform, and Build L3 requires a hardened build platform.
Source: SLSA v1.2: Build track basics (OpenSSF)GitHub Actions workflows can use OpenID Connect to request a short-lived access token directly from a cloud provider, so cloud credentials do not have to be stored as long-lived GitHub secrets.
Source: GitHub Docs: OpenID ConnectFor Amazon ECS deployments, AWS CodeDeploy shifts traffic to the updated task set with a canary, linear or all-at-once deployment configuration, and teams can create their own canary or linear configurations.
Source: AWS CodeDeploy User Guide: deployment configurationsAWS CodeBuild is a fully managed build service that compiles source code, runs unit tests and produces artifacts that are ready to deploy, without build servers to provision or scale.
Source: AWS CodeBuild User Guide
References
Which guidance do our pipelines follow?
The publications and vendor documents behind the stages, gates and deploy steps above.
NIST SP 800-204DNIST SP 800-218SLSA Build trackOpenID ConnectAWS CodeDeploy
Frequently Asked Questions
It depends on the number of services, the deployment targets and how healthy the test suites are. We agree the first pipeline, usually one service from commit to production, on the scoping call and reuse it as the template for the rest.
Yes. We build on your current source control, CI platform, artifact registry and cloud accounts, and connect ticketing, chat alerts and change records where your release process needs them.
Yes. We use AWS CodePipeline to orchestrate, CodeBuild for builds and tests and CodeDeploy for canary or linear traffic shifting, or deploy into AWS from GitHub Actions or GitLab CI/CD through OIDC roles.
Rolling deploys suit most stateless services at first. Add blue-green or canary where a bad release would be costly, and feature flags when product teams want to release to chosen users.
We set up OpenID Connect federation, so each pipeline job requests short-lived credentials for a role scoped to its repository and environment. Then we delete the long-lived keys.
Yes. A common first phase is one service with build once, required gates, signed artifacts and one production deploy strategy. Other services adopt the template afterwards.
AI tools may draft pipeline YAML or scripts, but every change goes through the same review, gates and test deploy as application code before it can touch production.