Your CI/CD pipeline probably looks something like this:
- Code pushed
- Tests run
- Linting checks
- Security scan
- Build
- Deploy
It's a well-oiled machine for getting code from commit to production. Teams spend months perfecting each step.
But there's a gap. The pipeline handles code that's actively being changed. It doesn't handle code that's sitting there accumulating dust.
Dependencies grow stale. Patterns become outdated. Dead code accumulates. Technical debt compounds. None of this triggers your pipeline because nothing changed—that's the problem.
The missing step: automated maintenance.
The Pipeline Blind Spot
Traditional CI/CD is reactive. It responds to changes. Push code, pipeline runs. No push, no pipeline.
This design assumes all important work comes through commits. But maintenance needs aren't triggered by commits:
- Dependency updates: New versions release regardless of your activity
- Security vulnerabilities: Disclosed on external timelines
- Code patterns: Become outdated as language/framework best practices evolve
- Dead code: Accumulates as features change and old code is abandoned
- Documentation: Drifts from reality without explicit updates
Your CI/CD pipeline is excellent at validating changes. It's blind to accumulating problems in unchanged code.
What Automated Maintenance Adds
Adding maintenance to your pipeline means checking and improving code health continuously, not just when someone makes a change.
Proactive Dependency Management
Instead of waiting for a developer to update dependencies:
# Nightly dependency check
name: Dependency Maintenance
on:
schedule:
- cron: '0 3 * * *'
jobs:
dependencies:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Check for updates
run: devonair scan dependencies
- name: Apply safe updates
run: devonair update dependencies --safe
- name: Create PR for breaking updates
run: devonair update dependencies --breaking --create-pr
Safe updates (patches, minor versions with passing tests) apply automatically. Breaking updates create PRs for review.
Continuous Security Patching
Don't wait for someone to notice a vulnerability alert:
# Security check every 6 hours
name: Security Maintenance
on:
schedule:
- cron: '0 */6 * * *'
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Scan for vulnerabilities
run: devonair scan security
- name: Patch critical vulnerabilities
run: devonair fix security --severity=critical --auto-merge
- name: Create PRs for other vulnerabilities
run: devonair fix security --create-pr
Critical vulnerabilities get patched automatically. Lower severity issues get PRs for review.
Code Health Monitoring
Track and improve code quality continuously:
# Weekly code health check
name: Code Health
on:
schedule:
- cron: '0 0 * * 0' # Weekly on Sunday
jobs:
health:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Scan for code issues
run: devonair scan code-health
- name: Fix automated issues
run: |
devonair fix dead-code
devonair fix unused-imports
devonair fix inconsistent-patterns
- name: Create improvement PR
run: devonair create-pr --title "Weekly code health improvements"
Dead code, unused imports, and pattern inconsistencies are cleaned up weekly without developer effort.
Documentation Sync
Keep documentation current as code evolves:
# Documentation check on code changes
name: Documentation Sync
on:
push:
paths:
- 'src/**'
jobs:
docs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Check documentation drift
run: devonair scan docs --compare-to-code
- name: Update outdated docs
run: devonair fix docs --auto-update
When code changes, documentation is checked and updated automatically.
The Complete Pipeline
With maintenance added, the full pipeline looks like this:
On Every Push (Reactive)
Push → Test → Lint → Security → Build → Deploy
Same as before. Validates and ships changed code.
On Schedule (Proactive)
Timer → Scan → Identify → Fix → PR → Review → Merge
New addition. Improves code health without commits.
On External Events (Responsive)
Vulnerability → Alert → Patch → Test → Auto-merge
Responds to external events (security disclosures, new dependency versions) without waiting for human awareness.
Implementation Patterns
Pattern 1: The Nightly Maintainer
Run comprehensive maintenance overnight when the system is quiet:
name: Nightly Maintenance
on:
schedule:
- cron: '0 2 * * *'
jobs:
maintain:
steps:
# Update dependencies
- run: devonair update deps --safe
# Fix code issues
- run: devonair fix lint
- run: devonair fix types
- run: devonair fix dead-code
# Update documentation
- run: devonair fix docs
# Create single maintenance PR
- run: devonair create-pr --title "Nightly maintenance $(date)"
Developers arrive to a maintenance PR ready for review each morning.
Pattern 2: Continuous Small Improvements
Instead of batch maintenance, apply small improvements continuously:
name: Continuous Maintenance
on:
push:
branches: [main]
jobs:
maintain:
steps:
- uses: actions/checkout@v3
# Quick maintenance checks after each merge
- run: devonair quick-fix --auto-commit
# If quick fixes were made, push them
- run: |
git push || echo "No fixes needed"
Every merge triggers a quick maintenance pass. Improvements compound over time.
Pattern 3: Risk-Based Automation
Automate different maintenance types based on risk:
name: Tiered Maintenance
on:
schedule:
- cron: '0 * * * *' # Hourly
jobs:
# Low risk: fully automated
low-risk:
steps:
- run: devonair fix formatting --auto-merge
- run: devonair fix lint --auto-merge
- run: devonair fix unused-imports --auto-merge
# Medium risk: auto-PR, manual merge
medium-risk:
steps:
- run: devonair update deps --patch --create-pr
- run: devonair fix dead-code --create-pr
# High risk: alert only
high-risk:
steps:
- run: devonair scan breaking-changes --alert
- run: devonair scan architecture-issues --alert
Fully automate what's safe. Create PRs for moderate changes. Alert on risky issues.
Measuring the Impact
How do you know automated maintenance is working?
Before Metrics (Capture These First)
- Average dependency age
- Number of security vulnerabilities
- Dead code percentage
- Lint warning count
- Documentation freshness score
After Metrics (Track Improvement)
- Dependency freshness: Should improve steadily
- Vulnerability window: Time from disclosure to patch should shrink
- Code health score: Should improve or stabilize
- Maintenance PRs merged: Track volume and accept rate
- Developer maintenance time: Should decrease
Leading vs. Lagging
Leading indicators (early signals):
- Maintenance PRs being created
- PRs being merged successfully
- Scan results showing issues
Lagging indicators (outcome measures):
- Overall code health improving
- Fewer production incidents from outdated dependencies
- Developer satisfaction with codebase quality
Common Objections
"This will create too many PRs"
Configure batching and frequency. A single weekly PR with accumulated improvements is often better than daily PRs. Find the rhythm that matches your team's review capacity.
"Automated changes might break things"
Every automated change runs through your existing test suite. If tests pass, the change is likely safe. If tests fail, the change doesn't merge. Your tests are the safety net.
"We need human review for all changes"
You still have it. Automated maintenance creates PRs—humans review and merge them. The automation handles the tedious creation work; humans retain final authority.
"Our codebase is too complex"
Complex codebases need automated maintenance more, not less. The complexity that makes manual maintenance impractical is exactly why automation is valuable.
"We already have Dependabot"
Dependabot handles one slice of maintenance (dependency versions). Automated maintenance covers the full spectrum: code patterns, dead code, documentation, security, and more.
Getting Started
Week 1: Dependency Updates
Start with the most obvious maintenance: keeping dependencies current.
name: Dependency Maintenance
on:
schedule:
- cron: '0 3 * * 1' # Weekly Monday
jobs:
deps:
steps:
- uses: actions/checkout@v3
- run: devonair update deps --patch --create-pr
Monitor the PRs created. Are they mergeable? Do tests pass? Adjust configuration based on results.
Week 2: Add Security
Layer in security patching:
- run: devonair fix security --create-pr
Security patches are high-value, usually low-risk. Good second step.
Week 3: Code Quality
Add code health improvements:
- run: devonair fix lint --create-pr
- run: devonair fix unused-code --create-pr
These improve code quality incrementally.
Week 4+: Full Integration
Expand to comprehensive maintenance. Tune frequency and batching based on team capacity.
The Maintenance-First Mindset
Traditional CI/CD asks: "Is this change safe to deploy?"
Maintenance-augmented CI/CD adds: "Is this codebase healthy?"
The first question is reactive—responding to developer actions. The second is proactive—ensuring code health regardless of activity.
The complete pipeline doesn't just ship code. It maintains a healthy codebase that's always ready to ship. Dependencies are current. Security is patched. Code is clean.
That's the step most pipelines are missing.
FAQ
How often should maintenance run?
Depends on the maintenance type. Security scans: frequently (hourly or on-push). Dependency updates: daily or weekly. Code health: weekly. Find the rhythm that keeps the codebase healthy without overwhelming reviewers.
What if maintenance PRs pile up?
You're probably running maintenance too frequently or not reviewing promptly. Either reduce frequency, increase batching, or allocate review time. The goal is continuous improvement, not PR accumulation.
Should maintenance block deployments?
Generally no. Maintenance PRs are improvements, not gates. However, critical security issues might warrant blocking until patched.
How do I handle maintenance across multiple repos?
Run maintenance pipelines on each repo. For organization-wide coordination, use centralized dashboards to track maintenance status across repos and prioritize cross-repo issues.
What's the difference between maintenance and regular CI checks?
CI checks validate changes you make. Maintenance proactively improves code regardless of changes. CI is reactive; maintenance is proactive. You need both.