What I automate / Deployments, environments and releases
Deploying should be a button
A small engineering team ships fine for a while, then accumulates a quiet tax: a deployment only one person is confident running, a page of instructions that is slightly out of date, environments that have drifted apart, credentials pasted into a config file two years ago, and backups nobody has ever restored.
None of it is urgent, which is exactly why it never gets done. It becomes urgent on the day someone is unavailable, or a release has to be undone at nine in the evening.
This is my day job. The work is not glamorous and does not take as long as people expect — a pipeline with a tested rollback is usually days, not months. What it takes is somebody deciding it is worth a fortnight of attention.
You probably know this is you if
- Deployment involves following written steps rather than running one thing
- Only one person is genuinely confident releasing to production
- Test and production have drifted and nobody is sure how far
- Rolling back is theoretical — it has never actually been done
- Credentials live in config files, chat history or someone's laptop
- There are backups, and there has never been a restore
The jobs in this area
Deploying by following a page of instructions
A pipeline that builds, tests, deploys and can roll back, so a release is a button rather than an evening.
Only one person being able to deploy
The same pipeline for everyone, with a record of who released what and when.
Setting up an environment by hand
Environments defined as code and recreated on demand, so test and production stop drifting apart.
A release that cannot be undone quickly
Versioned releases with a rollback that is tested, not theoretical.
Secrets pasted into config files and chats
Credentials moved into a proper store, injected at run time, and rotated without a code change.
Backups nobody has ever restored
Backups that run on schedule and a restore that is actually rehearsed, with the result recorded.
How a build like this goes
- 1
Start with the release path, because it is the thing that blocks everything else. Build, test, deploy, and a rollback that gets tested as part of the work rather than promised.
- 2
Then environments as code, so a new one can be created rather than assembled, and drift stops being invisible.
- 3
Then secrets out of files and into a proper store, injected at run time, rotatable without a code change.
- 4
Then a restore rehearsal. A backup nobody has restored is a hypothesis, not a backup, and the rehearsal is usually the most alarming half-day of the engagement.
- 5
All of it with your team, in your accounts, handed over to them. I am not trying to become a dependency.
A worked example
A pipeline for a team of six
- Before
- Manual deploys, roughly weekly, about two hours each with two people watching. One bad release a quarter, taking half a day to unpick.
- After
- A pipeline anyone on the team can run, with a rollback that has been tested. Deploys go from a scheduled event to a non-event.
2 hours × 2 people × 50 releases is 200 engineer-hours a year, plus the bad releases. Engineering time is expensive, so this is one of the few automations that pays back in months rather than quarters — and the real return is releasing more often because it stopped being frightening.
Those are illustrative figures, not a quote and not a promise. Your own numbers are the only ones that matter — the calculator does the same arithmetic on them.
What this normally costs
A job in this area is usually a connected module: ₹60,000 to ₹1,80,000, two to four weeks. The exact number comes from the audit, in writing, before anything is built.
The audit itself is ₹9,999 and comes off the first build in full. If it turns out this is not worth automating for you, that is what the report will say.
Questions about this kind of work
We already have developers. Why bring you in?
Because this work is never the most urgent thing on their list, and it competes with shipping features. I do it alongside them and hand it over — the goal is that your team maintains it, not that you keep calling me.
Which tools do you use?
Whatever you already run. If you are on GitHub, GitLab, AWS, Azure or GCP, that is what gets used. Introducing a new tool your team has to learn is a cost, and it needs to earn its place.
Can you do this without access to production?
The build, mostly yes. The final cutover needs someone with access, and that can be your engineer running it with me watching rather than the other way round.
Tell me about your version of this
Tell me the job you are tired of
One call, half an hour. You will get a straight answer about whether it is worth automating — including 'no' if that is the answer.