Procurement: CI/CD Tooling
What this is and who it’s for
This runbook tells you how to buy CI/CD tooling — the platform that builds, tests, and ships your code — on a Maryland contract vehicle without overpaying on seats or getting locked into a pipeline you can’t leave. It’s for an agency tech lead who needs the capability and the procurement officer who has to put it on a contract. It assumes you already know what good CI/CD looks like; the job here is converting that into a defensible requirement, the right delivery model, the right vehicle, a SOW you can stand behind, and an evaluation that picks a tool on merit. If you can’t yet describe your pipeline stages, your build concurrency needs, and your hosting boundary, stop and read the prerequisites first.
Prerequisites
- You’ve read the CI/CD — GitHub Actions runbook and can describe what a good pipeline does — build, test, scan, deploy — and what gates between stages. You cannot write a defensible requirement for a capability you can’t describe.
- If a self-hosted model is on the table, you’ve also read the CI/CD — Self-Hosted GitLab runbook so you understand what running your own pipeline infrastructure actually costs in operations.
- Your agency has determined its compliance posture for hosted services — whether StateRAMP or FedRAMP authorization is required, and at what impact level [VERIFY]. CI/CD systems touch source code and deploy credentials, so the hosting boundary narrows the vendor field before you start; settle it up front.
- You know, roughly, your scale: number of developer seats, peak build concurrency, and build minutes per month. Per-seat and per-minute pricing means scale, not features, usually decides the bill.
The practice
Run this as four moves in order: define the requirement, pick a delivery model, write the SOW, evaluate. The delivery model is the hinge decision — it changes the vehicle, the SOW, and the cost shape from licensing to infrastructure — so make it explicitly rather than letting a vendor make it for you.
Define the requirement
Write down four things before you talk to anyone: the pipeline stages you need, the seats and concurrency, the build minutes, and the compliance posture. State stages as outcomes (“every merge runs unit tests and a security scan,” “tagged releases deploy to staging automatically”), not product features. Capture scale as numbers — developer seats, peak concurrent builds, build minutes per month — since this is what drives cost at every vendor. Decide your hosting boundary: can build runners touch agency networks and secrets, and may source code leave your boundary [VERIFY StateRAMP/FedRAMP].
Choose a delivery model
SaaS platform (vendor-hosted)
The vendor runs the control plane and, optionally, the build runners; you pay per seat and per build minute. Examples are GitHub Enterprise Cloud and GitLab SaaS — named as examples, not endorsements. Fastest to stand up and lowest operational burden, but it sends source code and pipeline definitions to a third party, so the vendor must carry the required StateRAMP/FedRAMP authorization [VERIFY] and that requirement belongs in the SOW as a pass/fail gate. The procurement implication is licensing-as-cost: per-seat and per-minute pricing scales with your team and your build volume, not your budget, so price it at projected scale.
Self-hosted (GitLab or Jenkins)
You run the CI/CD control plane and the build runners on your own infrastructure. No per-seat SaaS licensing and full control of where source code and secrets live, which simplifies the compliance story because nothing leaves your boundary. The procurement implication is infrastructure-as-cost: the spend moves from license to the runner compute and the people who operate it, so you’re usually buying implementation and managed-operations services plus the underlying compute — not the software. Budget for the operations burden explicitly; a “free” tool is not free to run.
Cloud-provider-native pipelines
You use the CI/CD service built into the cloud provider your workloads already run on. Tight integration with the deploy targets and one less vendor relationship, and it typically inherits the provider’s existing authorization [VERIFY], which can shorten the compliance review. The procurement implication is usually an add-on to the existing cloud-services vehicle rather than a new contract, but the pipelines are provider-specific, so the data-and-exit clause matters more here, not less.
Map to a vehicle
Match the model to the smallest vehicle that fits. A SaaS subscription under the small-purchase threshold [VERIFY] may not need a full RFP; a multi-year enterprise seat deal will. Self-hosted implementation and managed-operations work is a services buy and may fit a master services vehicle. Confirm the candidate vehicles in Procurement notes before committing.
Write the SOW
Fork the skeleton in Reference implementation. Keep the pipeline stages, seats/concurrency, and compliance posture as explicit, testable requirements — not preferences. Put data ownership and exit — source repositories and pipeline definitions both — in writing every time, regardless of model.
Evaluate
Score against the published rubric, not against the demo. Weight data ownership/exit and compliance as gates: a tool that fails either is out, however slick the pipeline UI looks. Run the seat and build-minute numbers through each vendor’s pricing model and evaluate cost at projected volume, not at pilot volume.
Reference implementation
Fork this SOW skeleton. Every bracketed item is a decision you must make or a value a human must verify; do not ship it with placeholders intact.
# STATEMENT OF WORK — CI/CD TOOLING
### 1. Scope
The Contractor shall provide [SaaS subscription | implementation and managed operations | cloud-native add-on] for a CI/CD platform that builds, tests, scans, and deploys software for [AGENCY / SYSTEM]. Estimated scale: [N developer seats], [N peak concurrent builds], [N build minutes/month]. Term: [base period + option years].
### 2. Pipeline Capability
The platform shall provide:
- Build and test execution triggered on commit, merge, and tag.- Required status gates between stages, blocking merge/deploy on failure.- Security and dependency scanning integrated into the pipeline.- Deployment automation to [staging / production targets].
### 3. Seats and Concurrency
- **Developer seats:** [N], with [named | floating] licensing.- **Peak concurrent builds:** [N], without queuing beyond [target wait].- **Build minutes:** [N/month] included; overage priced per Section 8.
### 4. Build Runners
Runners shall be [vendor-hosted | self-hosted on AGENCY infrastructure]. Self-hosted runners shall run within [AGENCY] network boundary and shall not transmit source code or secrets outside it. Runner sizing and count: [N runners at SPEC] to meet Section 3 concurrency.
### 5. Security and Compliance
The service shall hold [StateRAMP | FedRAMP authorization at IMPACT LEVEL] for the term. Secrets shall be stored in [encrypted secret store] and never written to build logs. Source code [shall | shall not] leave the [AGENCY] boundary.
### 6. Data Ownership and Exit
All source repositories and pipeline definitions are the property of [AGENCY]. On termination the Contractor shall, within [N days], export all repositories, pipeline configuration, and build history in [open format / standard Git] at no additional charge and certify deletion of agency data. No proprietary pipeline format shall prevent migration to another platform.
### 7. Support and Onboarding
The Contractor shall provide implementation, pipeline migration, runner configuration, and knowledge transfer sufficient for [AGENCY] staff to operate the platform unaided by end of [period].
### 8. Service Levels and Pricing
- **Platform availability:** [e.g. 99.9%] measured monthly.- **Support response:** [severity tiers and response times].- **Pricing** shall be stated at the estimated scale in Section 1 AND at [+50% | +100%] of that scale, so cost growth is visible before award. [FILL IN: ceiling / NTE amount per agency budget authority.]Score every responsive bid against this rubric. Treat the two gate rows as pass/fail: a failure on either eliminates the bid regardless of total score.
| Criterion | Weight | Notes |
|---|---|---|
| Compliance authorization (gate) | Pass/fail | StateRAMP/FedRAMP at required level [VERIFY] |
| Data ownership and exit (gate) | Pass/fail | Repos + pipelines exportable, no lock-in |
| Cost at projected scale | 30% | Scored at +50%/+100% seats and minutes, not pilot |
| Pipeline capability | 20% | Build, test, scan, gate, deploy completeness |
| Operational burden | 15% | Staff effort to run runners and platform |
| Integration fit | 15% | Works with current source control, cloud, deploy targets |
| Support and onboarding | 10% | Response SLAs, migration, knowledge transfer |
| Scalability headroom | 10% | Concurrency and pricing at growth |
Common pitfalls
- Per-seat licensing balloons as the team grows. Seat pricing looks cheap for a pilot team and ruinous at agency scale, especially when contractors and occasional committers each consume a paid seat. Require pricing at +50%/+100% of projected seats and build minutes before award, as in SOW Section 8, and confirm whether seats are named or floating.
- The “free” self-hosted tool isn’t free. A no-license tool like Jenkins or self-hosted GitLab moves the cost to runner infrastructure and the staff who keep it patched and online. Budget the runner compute and the operations labor in SOW Sections 4 and 7; the real procurement is services and compute, not software.
- No data-exit clause, so you’re locked in. If the contract has no clause exporting both source repositories and pipeline definitions in an open format, the vendor owns your leverage at renewal and a migration becomes a rewrite. SOW Section 6 is non-negotiable; make it a rubric gate.
- Compliance authorization was an afterthought. Discovering at award that a vendor lacks the required StateRAMP/FedRAMP authorization [VERIFY], or that runners ship source code outside the boundary, restarts the procurement. Make it a pass/fail gate in evaluation, not a scored line item.
- You bought the tool before defining the requirement. If the demo happened before the seat, concurrency, and build-minute numbers existed, you bought features, not fit. Go back to “Define the requirement,” then re-evaluate against the rubric.
Procurement notes
Candidate Maryland vehicles depend on the delivery model and dollar value, and must be confirmed with your procurement officer.
- SaaS platform subscription: [FILL IN: Maryland contract vehicle — e.g. COMMBUYS master contract # / NASPO ValuePoint cloud vehicle].
- Self-hosted implementation and managed-operations services: [FILL IN: Maryland IT master services vehicle #].
- Cloud-provider-native pipelines: amend the existing cloud-services contract [FILL IN: vehicle / order #].
Thresholds decide the path. Below the small-purchase threshold [VERIFY] you may avoid a full solicitation; above it you run an RFP against this runbook’s SOW and rubric [VERIFY]. A typical timeline runs roughly [VERIFY: e.g. 4–8 weeks for a small purchase, 3–6 months for a competitive RFP] — confirm against current Maryland procurement guidance before you commit a date to anyone.
For SOW drafting mechanics beyond this skeleton, see How to write a good SOW.
Maintenance
Owner: [FILL IN: runbook owner] · Last reviewed: 2026-05-31 · Next review: 2026-08-31