The ship-and-maintain cycle: how to automate everything after git push

The gap between shipping code and maintaining what you shipped is where most engineering debt lives. The code ships; the docs don't update; the tests gradually get skipped; the observability gaps don't get filled. This is the ship-and-maintain problem, and it's structural.

A modern post-push automation stack can close most of this gap. Here's what to automate after git push.

What "after git push" means

After a push to main, several things should happen without human intervention:

Tests run and block deployment if they fail
Security scans check for new vulnerabilities
Documentation gets reviewed and updated if needed
Deployment proceeds to staging, then production
Monitoring checks that nothing degraded

Most teams automate the first and fourth item. The others are still mostly manual, which means they mostly don't happen.

Documentation: the most skipped step

Documentation maintenance is the easiest automation win that most teams haven't taken. The reason it's usually skipped is that it feels like a content problem, not an engineering problem. But it's an engineering problem: you need a reliable process that runs after every merge and keeps your docs accurate.

DocDr handles this. It reads your merged PRs, compares the diffs against your Markdown documentation, and opens draft PRs with proposed updates. You review and merge. The cycle time from code merge to doc PR is typically under two minutes.

The design matters here: draft PRs, not auto-merges. An LLM can misunderstand technical specifics. Every proposed doc change gets human review before it ships. The automation handles the detection and drafting; you handle the approval.

Changelog generation

If you maintain a CHANGELOG, this is another candidate for automation. Tools like git-cliff can generate conventional-commit-based changelogs automatically. Wire it to your release workflow:

- name: Generate changelog
  uses: orhun/git-cliff-action@v2
  with:
    config: cliff.toml
    args: --verbose
  env:
    OUTPUT: CHANGELOG.md

This only works if your team writes meaningful commit messages. If they don't, fix that first — no automation can generate useful changelogs from "fix stuff" and "wip".

Deployment hygiene

After deployment, a smoke test job that hits your key endpoints and checks for expected responses will catch deployment failures before users do. Keep it minimal — 5-10 critical paths, not a full integration test suite. The goal is fast failure detection, not comprehensive coverage.

- name: Smoke test
  run: |
    curl -f https://your-app.com/health || exit 1
    curl -f https://your-app.com/api/status || exit 1

The full cycle

A team that has automated the ship-and-maintain cycle spends less time on maintenance tasks and more time building. The pipeline handles: secret scanning, dependency updates, documentation maintenance, deployment, and basic smoke testing. Engineers handle: code review, doc review, incident response.

The automation doesn't replace judgment — it handles the mechanical parts so judgment can focus where it matters.