DevOps before GitHub wasn't some quaint prehistory: it was Subversion, hand-cobbled deployment scripts and production releases that rarely finished on schedule. The real difference between then and now has less to do with GitHub itself than with what we learned about team coordination. Understanding that history helps you see what automation actually solved, and what it never did.
- 📈 SVN before Git, decentralised version control predates GitHub by several years.
- ⚠️ Manual deployments, before CI/CD went mainstream, every production release depended on a human and a homegrown script.
- 💡 GitOps since 2017, Git becomes the single source of truth for infrastructure, not just application code.
- 🚀 The tool doesn't make the engineer, automation reduces operational friction, not the need for technical judgement.
This might sound like a software archaeology topic. It isn't: the same coordination mistakes are resurfacing today, simply dressed up behind YAML pipelines.
DevOps existed long before GitHub, and it was a coordination nightmare
A developer asked on r/ExperiencedDevs what daily life was like for those who worked before GitHub and modern DevOps tooling. A near-identical post showed up on r/developersIndia, proof that the question isn't tied to one generation or one geography. The starting point in both threads is the same: managing branches, merges, builds and deployments with Subversion or Tortoise SVN required heavy coordination and a great deal of manual operational effort.
Before automation, a server update was often done by hand, a configuration was edited directly in production, and a script ran with no safety net. I caught the tail end of that era from a distance early in my career, and the number one symptom wasn't slowness: it was unpredictability. Two environments that were supposed to be identical always ended up diverging, and nobody knew exactly why.
How did you deploy an application before Git and CI/CD?
Deployment relied on a combination of manually updating servers, editing configurations directly and running ad hoc scripts, with no centralised automation. Rolling back to a previous version when something went wrong was complex and risky, because there was no reliable, versioned history. Configuration drift between development, test and production environments was a recurring problem, hard to diagnose because nobody had a clear overall view of the system's actual state.
GitOps changed the rules of the game from 2017 onwards
That manual friction is precisely what GitOps went after. The concept was introduced in 2017 by Weaveworks, as a tutorial from the Thinknyx Technologies channel on the subject points out. The core idea: treat infrastructure, configuration and operational policies as code, stored in a Git repository that becomes the system's single source of truth.
In practice, a developer pushes a change to the repository. A tool such as Argo CD, GitHub Actions or Jenkins watches that repository and automatically applies the change to the target infrastructure. The system stays permanently in sync with the state described in Git, which makes deployments more predictable and rollbacks as simple as reverting to an earlier commit.
What are push and pull deployments in GitOps?
In a push deployment, an automated pipeline, often Jenkins, actively sends changes from the repository to the target environment as soon as a commit is detected. In a pull deployment, an agent running inside the environment, such as Argo CD, continuously watches the repository and fetches the changes itself to adjust the infrastructure. The difference sounds technical, but it changes who triggers the change: the pipeline in one case, the environment itself in the other.
The market for CI/CD and infrastructure automation tools keeps growing at double-digit rates every year, a trend that analyst firms like Gartner track closely through the lens of DevOps platform consolidation. GitHub, for its part, was a latecomer to this space. According to a comparison published by journaldunet.com, GitLab built in a CI/CD component as early as 2012, whereas GitHub, acquired by Microsoft in 2018, only entered the field at the end of 2019 with the launch of Actions. The name that dominates the DevOps imagination today is therefore not the one that invented the discipline. It caught up with it.
Automation solves friction, not technical judgement
Where I part ways a little with the prevailing narrative is on the idea that GitOps or GitHub Actions have solved the DevOps problem once and for all. They solved one specific problem: configuration drift and the lack of traceability. They never solved the question of whether the architecture behind the pipeline made any sense.
A perfectly configured CI/CD pipeline can deploy a bad architecture with formidable reliability. In a sense, it's even worse than before: execution speed hides poor design choices for longer. A botched manual deployment was visible immediately. A bad architectural choice, automated, can hold for months before the bill arrives, often in the form of technical debt or a cascading incident.
Why does a good CI/CD pipeline never replace a senior engineer?
A pipeline executes what it was told to execute; it never questions whether that's the right thing to execute. The decision to break up a monolith, choose a database, size a cluster or weigh time-and-materials against fixed-price remains a human judgement, one that no automation tool is meant to carry. It's a problem of architecture and accountability, not a tooling problem.
That's exactly what I see with AI tools applied to development: they speed up the execution of a decision, never the decision itself. A developer using Claude Code or Cursor is still an engineer who has to understand the business need, not a prompt operator hoping the output survives production.
GitHub, GitLab, Cycloid: the platform matters less than the team using it
The journaldunet.com comparison, covering integrated DevOps platforms on the French and international markets, gives a good snapshot of who covers what. GitLab comes out as the most complete solution natively, GitHub stays strong on ecosystem and security, and Cycloid, a French player, positions itself on multi-cloud infrastructure as code.
| Criterion | GitHub | GitLab | Cycloid |
|---|---|---|---|
| Built-in Git / bug tracking | Yes | Yes | No |
| Multi-cloud IaC | No | Yes | Yes |
| Configuration management | No | Yes | Yes |
| Native CI/CD | Yes (Actions) | Yes (GitLab CI) | Yes |
| Infrastructure designer | No | No | Yes |
SOURCE: journaldunet.com, DevOps platform comparison · Updated 07/2021
On paper, the table gives a clear answer. In practice, I've seen teams get excellent results from a minimalist GitHub stack, and others bog down on a full GitLab stack because nobody on the team really mastered infrastructure as code. The platform sets the ceiling of what's possible. It never guarantees the team will reach it.
What this means for an AI-augmented offshore team
Full disclosure: I run an offshore software services company in Vietnam, so I have an obvious bias on this topic, and it's also why I get a close-up view of where automation genuinely helps and where it only serves to reassure a board over PowerPoint. The equation I defend isn't new, but GitOps and generative AI make it more legible than before: a small senior team, well tooled, that masters both the pipeline and the architecture behind it, beats a team twice its size that stacks up tools without understanding why.
In May 2026, a Paris-based client showed me their six-year-old GitHub Actions pipeline, untouched since the security audit that had put it in place. The tool still worked. The architecture it was deploying, on the other hand, had racked up enough technical debt to justify a complete rebuild. GitOps hadn't prevented any of it: it had simply kept the debt invisible for longer.
The advantage of a senior, AI-augmented Vietnamese team doesn't come from any particular DevOps tool; it comes from the combination of architectural skill and execution speed. I've already detailed how that combination translates into concrete savings in an article on the real gains of an offshore team equipped with Claude Code. The same principle applies to DevOps: the most modern pipeline on the market never saves a project where nobody masters the infrastructure end to end, and AI-generated code raises exactly this question of accountability when an automated deployment pushes to production a mistake a human would have caught in five minutes.
Modern DevOps rewards teams that can still read a pipeline line by line, not just those who can configure one from a template. That's been true with GitOps since 2017, and it's still true with AI in 2026.
"Automation never replaced a good engineer's judgement. It just changed where you spend it."
Vincent Roye, August 2026
The thread running through this story, from pre-GitHub SVN to today's AI agents, fits in one sentence: every generation of tools promises to solve the human problem of DevOps, and every generation ends up pushing that problem one step further along. That's not a failure of the tools. It's just their actual role.
The verdict: DevOps before GitHub explains why teams still win on judgement, not tooling
No, GitHub didn't invent DevOps, and DevOps before GitHub wasn't simply a slower version of today's: it was a discipline that rested almost entirely on human discipline, for lack of automated guardrails. GitOps brought those guardrails from 2017 onwards, and that's genuine progress. But a guardrail stops you from falling; it doesn't choose the direction.
For a team hiring or outsourcing its DevOps capacity in 2026, the question to ask is no longer "which tool do you use?". It's "who on the team understands why this pipeline was built this way". If nobody can answer, no platform, however complete, will solve the problem on their behalf.
Frequently asked questions
Did DevOps really exist before GitHub?
Yes. DevOps practices for configuration management, version control and deployment existed with tools like Subversion, Ansible or Jenkins long before GitHub became a central player. GitHub joined this space late, with the launch of GitHub Actions at the end of 2019.
What is GitOps and how does it differ from classic DevOps?
GitOps is a practice introduced in 2017 that uses Git as the single source of truth for infrastructure and applications, not just for code. Unlike classic DevOps, where deployment scripts could be run manually, GitOps automates the application of changes as soon as a commit is detected in the repository.
GitHub, GitLab or Cycloid: which platform should a DevOps team choose?
GitLab natively covers the broadest functional scope, from configuration management to infrastructure as code. GitHub remains the reference for ecosystem and code security, while Cycloid, a French player, stands out on multi-cloud infrastructure as code. The right choice depends above all on the technical maturity of the team that will operate the platform day to day.
Does DevOps automation really reduce the need for senior developers?
No, it shifts that need rather than removing it. An automated pipeline faithfully executes the architectural decisions it's been handed; it never questions them. Human expertise is still required to design that architecture, diagnose drift and make the technical trade-offs no tool can make in an engineer's place.
Why does an AI-augmented offshore team have an edge in modern DevOps?
Because the edge doesn't come from a specific DevOps tool but from the combination of architectural skill and the execution speed that AI enables. A senior team that masters both the pipeline and what it deploys gets a real benefit from automation, whereas a team that stacks up tools without understanding them merely pushes its technical debt further down the road.
Vidéos YouTube
Discussions Reddit
- Developers who worked before GitHub and modern DevOps tooling — r/ExperiencedDevs
- How hard was software development before GitHub and modern DevOps tools? — r/developersIndia
