CI/CD Pipelines Built and Run for Software Teams
ITECS builds and runs CI/CD pipelines in GitHub Actions or Azure Pipelines for software teams in Dallas-Fort Worth. Each change is built once, tested and checked in staging, then approved by a person you name before production. Every release can roll back. Jobs reach your cloud with short-lived OIDC credentials instead of stored keys.
- Who it is for
- Engineering leads who own the release pipeline
- What ITECS builds
- Build, test, staging and release automation
- What ITECS runs
- Pipelines inside your repositories and accounts
- Pricing
- Custom-scoped. The assessment ends in a written plan, the order of work and a quote for the first piece. How pipeline work is priced
- After launch
- Run by ITECS, or handed to your team with runbooks
Scope
What a pipeline build covers
ITECS builds in the CI system you already run, and every change to it is a pull request your engineers review.
- Build and test
- One build per change, with the tests and scans your team marks as required before a merge.
- Cloud credentials
- Jobs sign in with short-lived OIDC tokens that a cloud role trusts only for a named repository and environment. Stored cloud keys come out of CI.
- Supply chain
- Third-party actions and tasks are pinned to a full commit, and each job's token carries only the permissions that job needs.
- Environments
- Staging and production are defined the same way, and production has protection rules the pipeline cannot skip.
- Release controls
- A named approver for production, a record of what each release changed and a rollback path for each release.
- Cost and queue time
- Runner minutes, queue time and failed runs are tracked per pipeline, so a slow or costly pipeline shows up before engineers start working around it.
- AI features
- Prompt and model changes run an evaluation in CI before they merge, the way code runs its tests.
Scenario
A pipeline with stored cloud keys and no way back
Illustrative planning scenario, not a reported client result or a named public case study.
- Starting point
- A software team runs GitHub Actions across several repositories. Long-lived cloud keys sit in the repository settings, some workflows call third-party actions by tag and production deploys straight from the main branch. When a release breaks, someone pushes a fix forward, because nobody has tested going back.
- Scoped outcome
- The written plan replaces the stored keys with OIDC roles scoped to each repository and environment, and pins every third-party action. It adds a staging step and a release approval. One service moves first and proves its rollback in staging, then the rest follow. After the move, queue time and runner cost are watched under managed DevOps.
Approach
How ITECS changes a pipeline that is in use
Your releases keep shipping while the pipeline changes.
Read what runs today
ITECS reads your workflows, runners, stored secrets and release history, and sits in on a release with the engineer who usually runs it.
Set the release rules
You decide which checks block a merge, who approves production and how a release rolls back. ITECS writes the rules down before it builds anything.
Build in pull requests
Pipeline changes land as pull requests in your repositories, and your engineers review each one before it merges.
Move one service first
One service moves to the new pipeline before the others, so a problem shows up in one place. The rest follow in the order the plan sets.
Run it or hand it over
ITECS runs the pipelines under managed DevOps, or your team takes them over with the runbooks and a walkthrough.
Pipeline
From commit to production
Every change takes the same path. Production waits at the diamond until a person you name approves the release.
Your repository
Commit
A change starts as a commit on a branch. The pipeline definitions live in the same repository and change the same way.
Output: Change on a branch
Pull request
Your engineers review the change. Branch protection holds the merge until the review and the required checks pass.
Output: Reviewed change
Your CI system
CI checks
The change is built once, tested and scanned. Jobs sign in to the cloud with a short-lived OIDC token, and third-party actions run pinned to a commit.
Output: Built artifact
Staging
The same artifact deploys to staging. Smoke tests run there, and so does the rollback.
Output: Staging results
Sign-off
A person you name approves the release in the CI system. Production waits until they do, and the approval is recorded with the release.
Output: Approved release
Your approval
Your cloud account
Production
The artifact that passed staging deploys to production. Each release records what changed and who approved it.
Output: Live release
Monitoring
Error rates and latency are checked after each release. The pipeline can redeploy the last good build, and a person decides when to roll back: the release approver or the on-call engineer under managed DevOps.
Output: Release health
Rollback: last good build
Dashed output waits for approval. Rollback redeploys the last good build.
Deliverables
What your team keeps
- Pipeline definitions in your repositories, written in your CI system's own format.
- A written release policy: the required checks, the approvers and the rollback steps.
- OIDC trust policies for each cloud account, with the allow and deny cases tested.
- A rollback runbook for each service on the pipeline, tested in staging.
- A view of runner cost, queue time and failed runs for each pipeline.
- Ownership of every runner, role and file ITECS sets up, written into the scope.
Where it fits
Where pipeline work fits
Pipeline work starts from the assessment's written plan. It often comes first, because infrastructure and platform changes ship through the pipeline too.
- DevOps assessment
- Sets whether the pipeline comes first and what it must fix, before ITECS quotes the build.
- DevOps services
- The hub for the services a pipeline works with: Kubernetes platforms, infrastructure as code, observability and managed DevOps.
- Linux server support
- ITECS's Linux practice on itecsonline.com can patch, harden and support self-hosted Linux runners and build servers.
- Managed Azure cloud
- Through managed Azure on itecsonline.com, ITECS can run the subscription your pipeline deploys to. The OIDC federation stays pipeline work.
- Federate CI jobs with OIDC
- The ITECS guide to Claude Platform on AWS shows how to bind a CI job's cloud role to one repository and an approved branch or environment, then test the deny cases.
Pricing
How pipeline work is priced
Pipeline work is custom-scoped. The assessment shows how many repositories, services and environments are involved, and the quote follows from it.
- Assessment
- The entry point. It ends in a written plan that sets the order of work, and a quote for the first piece of work comes with it.
- What moves the quote
- The repositories and services that move, where the pipeline deploys and which approvals your release policy needs.
- Pipeline build
- Quoted from the written plan you approve.
- Managed DevOps
- A retainer that covers the pipelines ITECS operates and the response coverage you choose.
- CI and cloud
- Runner minutes, CI subscriptions and cloud accounts stay client-paid unless a proposal states pass-through billing.
Published AI package prices do not apply to DevOps work.
FAQ
CI/CD pipeline FAQ
What do CI/CD pipeline services include?
CI/CD pipeline services build and run the path a change takes from commit to production: build, tests, scans, staging, a release approval and rollback. ITECS builds them in GitHub Actions or Azure Pipelines for software teams in Dallas-Fort Worth and across the United States.
Do we have to change CI systems?
No. ITECS works in the CI system you already run, GitHub Actions or Azure Pipelines. A move to another system happens only when the written plan calls for it and says why.
How do you keep cloud keys out of the pipeline?
Each job requests a short-lived token through OIDC, and each cloud role trusts only a named repository, branch or environment. ITECS tests that an unapproved branch is denied before the old stored key is deleted.
Who approves a production release?
A person you name. In GitHub the approval is a required reviewer on the production environment, and in Azure Pipelines it is an approval check. Either way it is recorded with the release.
How does rollback work?
Each release deploys a versioned build. The pipeline can redeploy the last good build, and a person decides when to roll back: the release approver or the on-call engineer under managed DevOps. Your engineers write database migrations so the previous build still runs against the new schema, and ITECS checks that in staging before a service moves.
Why is our pipeline slow?
Most slow pipelines rebuild what could be cached, run every test on every change or wait for a free runner. ITECS measures queue time and run time for each job first, then fixes the longest wait.
Should our own engineers do this instead?
Yes, if they have the time. The GitHub Actions and Azure Pipelines documentation covers OIDC and environments. ITECS is for teams whose engineers are busy shipping product. It moves your services in order, proves each rollback and then runs the pipelines or hands them over with runbooks.
Can ITECS run the pipelines after the build?
Yes. Under managed DevOps, ITECS watches failed runs, queue time and runner cost, keeps pinned actions current and answers alerts within the coverage in the retainer. It applies the operating practice ITECS has used for managed IT and security since 2002, including a 24/7 NOC.
Start with the pipeline you have
Tell us which CI system you run, where it deploys and what breaks on release day. You get back a written plan that sets which services move to the pipeline first, and a quote for moving them.