If We Replace Our SCM, Does Deployment Come With It? — A Question of Scope

When we meet an organization evaluating an SCM replacement, the questions usually arrive in this order. "Beyond version control, does it handle deployment too?" And then, immediately: "Can it be installed on our servers? We run UNIX."

The first question is about what our product fundamentally is. The second is about the actual machine room. Both deserve real answers, so here they are.

Are we just replacing the SCM, or does deployment come with it?

Deployment comes with it. More precisely, CollabOps isn't a drop-in replacement for an SCM tool. It's a platform where issues, repositories, change requests, pipelines, deployments, and audit logs live on one plane from the start. Version control is one piece of that plane.

The distinction matters because getting "SCM plus deployment" as two separate tools and getting it as one plane are different in kind, not degree. With two tools, someone has to wire them together with APIs and webhooks, and that wiring becomes a thing you maintain. On one plane, a change-request approval is directly an input to the deployment gate. Code that passes review gets built and deployed automatically, execution logs stream in real time, and when something fails, the per-stage cause links straight back to the change request and the issue. Some things only exist on top of that structure. I made the long version of this argument in the waterfall SI post, so here I'll stay on the deployment details.

For what it's worth, if you already operate a CI server, you don't have to throw it away. Separate from our native execution engine (pipeline runs execute as Kubernetes pods), you can connect an existing build server to the platform and lift only change requests, reviews, deployment approvals, and audit logging onto the shared plane. Whether migration or coexistence is right for you is the subject of migration vs. integration.

How is deployment controlled?

Deployments are separated by environment, and a production deployment runs only when every gate condition is met. Dev, staging, and production are distinct, and the path to production carries conditions: the required number of change-request approvals, passing tests, a clean security scan, change approval, an operator's sign-off, an existing rollback plan, and an approved deployment window. It's public-sector DevSecOps requirements translated directly into gates.

There's also the part after the deployment leaves. Every deployment lands in the audit log, and when something goes wrong, you roll back. Which change request went to which environment under whose approval remains a queryable record. An organization that started out evaluating an SCM replacement ends up acquiring this evidence chain — that's the actual purchase.

Does it install on UNIX servers?

The platform itself does not install on UNIX. It's Linux-container based, and I don't want to blur that. CollabOps deploys as containers on Kubernetes (or a lightweight single-VM configuration), with a minimum footprint of one VM, 8 vCPU, 16 GB RAM, 200 GB disk. One term worth untangling here: major Linux distributions, including the Red Hat (RHEL) family, Ubuntu, and Rocky, are all fully supported. Linux is not UNIX, and being container-based means the platform doesn't care which distribution it lands on. What isn't supported is actual UNIX — AIX, Solaris, HP-UX. Those differ from the CPU architecture up and have no container ecosystem, so installing the platform directly on them is not a supported configuration.

But peel the question back one layer and the real question is usually different: "Our systems run on UNIX — can you manage that source, and deploy to those machines?" That's a separate matter. The server the platform installs on and the server a deployment arrives at are not the same server. Managing the source of a UNIX-hosted system in Git, building it, and shipping the artifact to that machine works regardless of where the platform lives. In meetings these two questions tend to arrive fused into one, and separating them makes the answer obvious. The practical homework is securing one Linux VM for the platform, and in most organizations we've seen, that was never the hard part.

Instead of a summary, one piece of practical advice. If you're evaluating an SCM replacement, don't scope the project as "replace the version control tool." Compare candidates on the entire path a change travels from approval to production. The cost of switching is similar either way, but scope it the first way and deployment and evidence remain somebody else's problem.