Release Workflow

You are a DevOps/Release Engineer. The user wants to automate their release workflow by generating changelogs, versioning, tagging, and publishing releases programmatically.

What to check first

• Run git log --oneline -10 to verify git history is clean and commits are semantic
• Check if CHANGELOG.md exists in the root; if not, you'll initialize it
• Run npm list conventional-changelog-cli to see if changelog tool is installed

Steps

1. Install conventional-changelog-cli and semver as dev dependencies: npm install --save-dev conventional-changelog-cli semver
2. Create a .releaserc.json config file in the root with semantic versioning rules and changelog format
3. Write a release script that reads the current version from package.json using Node.js fs module
4. Calculate the next version by parsing commits since last tag using conventional-changelog analysis
5. Generate changelog entries by running conventional-changelog and prepending to existing CHANGELOG.md
6. Update package.json and package-lock.json with the new version using npm version
7. Commit the changelog and version bump with message chore(release): v{newVersion}
8. Create a git tag with git tag -a v{newVersion} -m "Release v{newVersion}" and push with git push origin main --tags

Code

#!/usr/bin/env node

const fs = require('fs');
const path = require('path');
const { execSync } = require('child_process');
const semver = require('semver');

const packageJsonPath = path.join(process.cwd(), 'package.json');
const changelogPath = path.join(process.cwd(), 'CHANGELOG.md');

// Read current version
const packageJson = JSON.parse(fs.readFileSync(packageJsonPath, 'utf8'));
const currentVersion = packageJson.version;

// Get last git tag or use v0.0.0 as fallback
let lastTag = 'v0.0.0';
try {
  lastTag = execSync('git describe --tags --abbrev=0', { encoding: 'utf8' }).trim();
} catch (e) {
  console.log('No previous tags found, starting from v0.0.0');
}

// Analyze commits since last tag to determine version bump
const commitLog = execSync(`git log ${lastTag}..HEAD --oneline --pretty=format:"%s"`, {
  encoding: 'utf8'
});

let bumpType = 'patch';
if (commitLog.includes('BREAKING CHANGE:') || commitLog.includes('!:')) {
  bumpType = 'major';
} else if (commitLog.includes('feat:')) {
  bumpType = 'minor';
}

// Calculate new version
const newVersion = semver.inc(currentVersion, bumpType);

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change