Release Management

Partner Documentation

Manage versions and releases for your DCS-integrated site.

Version Strategy

DCS uses semantic versioning (semver):

MAJOR.MINOR.PATCH

Type	When	Example
MAJOR	Breaking changes	2.0.0
MINOR	New features	1.1.0
PATCH	Bug fixes, text changes	1.0.1

Release Branches

Branch Structure

main ─────────────────────────────────────────────► main
  │                                                   ▲
  └── release/1.2.0 ──(dev work)──(deploy)──(merge)──┘
                                              │
                                              └── tag: v1.2.0

Creating a Release Branch

# From main, create release branch
git checkout main
git pull origin main
git checkout -b release/1.3.0
git push origin release/1.3.0

Release Branch Naming

Use the pattern: release/{version}

Examples:

• release/1.0.0
• release/1.2.0
• release/2.0.0

Development Workflow

1. Start New Version

In the portal:

1. Go to Site → Releases
2. Click "Create New Version"
3. Enter version number
4. Branch is created automatically

2. Make Changes

Development requests and direct work go to the release branch:

git checkout release/1.3.0
# Make changes
git commit -m "Add new feature"
git push

3. Preview and Test

• Changes deploy to development environment
• Test in the preview site
• Make adjustments as needed

4. Finalize Release

When ready for production:

1. Go to Site → Releases → Current Version
2. Click "Finalize Release"
3. Release branch merges to main
4. Tag is created
5. Production deploys

Version Bumping

Automatic Bumping

DCS automatically suggests version bumps based on changes:

Change Type	Suggested Bump
Text overrides only	No bump needed
Config changes	PATCH
New widgets	MINOR
New pages	MINOR
Layout changes	MINOR
Breaking changes	MAJOR

Manual Override

Override the suggested bump in the portal or via commit message:

git commit -m "Add search feature

[version: minor]"

Release Notes

Automatic Generation

DCS generates release notes from:

• Commit messages
• Development requests
• Text override changes

Example Release Notes

## v1.3.0 (2024-01-15)

### New Features
- Added testimonials section to home page (#123)
- Created new pricing page (#125)

### Improvements
- Updated hero section styling (#124)
- Improved mobile navigation

### Content Updates
- 15 text overrides committed
- Updated SEO metadata for 5 pages

### Contributors
- Jane Doe (3 commits)
- John Smith (2 commits)
- GitHub Copilot (3 commits)

Custom Release Notes

Add custom notes in the finalization dialog or via a RELEASE_NOTES.md file.

Tagging

Tag Format

v{version}

Examples:

• v1.0.0
• v1.2.3
• v2.0.0

Tag Contents

Tags include:

• Version number
• Release date
• Commit SHA
• Release notes

Viewing Tags

git tag -l
git show v1.2.0

Hotfixes

For urgent production fixes:

1. Create Hotfix Branch

git checkout main
git checkout -b hotfix/1.2.1

2. Make Fix

# Fix the issue
git commit -m "Fix critical bug"

3. Deploy Directly

Hotfixes can bypass the normal release flow:

1. Go to Site → Releases
2. Click "Emergency Deploy"
3. Select hotfix branch
4. Confirm deployment

4. Merge Back

# Merge to main
git checkout main
git merge hotfix/1.2.1

# Also merge to current release branch
git checkout release/1.3.0
git merge hotfix/1.2.1

Rollback

Via Portal

1. Go to Site → Releases
2. Find the version to rollback to
3. Click "Rollback"
4. Confirm

What Happens

• Git reverts to the previous release
• A new patch version is created
• Production deploys the reverted code

Rollback Limitations

• Text overrides are not affected (API-based)
• External integrations may need manual update
• Database changes are not automatically reverted

Change Tracking

View Changes

In the portal:

1. Go to Site → Releases → Current Version
2. Click "View Changes"
3. See all changes since last release

Change Types

Icon	Type	Description
📝	Text	Text override changes
🔍	SEO	SEO metadata changes
💻	Code	Code changes (dev requests)
📄	Page	New or modified pages
🧩	Widget	Widget additions/changes

Release Approval

Approval Settings

Configure in Site → Settings → Releases:

• Auto-approve patches — Deploy patch versions automatically
• Required approvers — Users who must approve major releases
• Approval timeout — Auto-reject after N days

Approval Workflow

1. Release is ready
2. Approvers are notified
3. Each approver reviews changes
4. All required approvals received
5. Release deploys to production

Multiple Sites

Coordinated Releases

For sites that depend on each other:

1. Create release branches with same version
2. Develop changes in parallel
3. Finalize in correct order
4. Use dependencies in workflow

Shared Components

If sites share components:

• Update shared package first
• Bump version in dependent sites
• Test integration before release

Best Practices

1. Regular Releases

• Release frequently (weekly/bi-weekly)
• Smaller releases = lower risk
• Keep release branches short-lived

2. Clear Commit Messages

feat: Add customer testimonials section

- Added 3 testimonial cards
- Responsive design for mobile
- Integrated with useTextContent

Closes #123

3. Test Before Finalizing

• Always verify in development environment
• Test on multiple devices
• Check performance metrics

4. Document Breaking Changes

## v2.0.0 - Breaking Changes

### API Changes
- `useTextContent` now returns `{ t, isLoading, error }` instead of just `t`

### Migration Guide
1. Update composable usage
2. Handle loading state
3. Test error scenarios

5. Clean Up Old Branches

# Delete merged release branches
git branch -d release/1.1.0
git push origin --delete release/1.1.0

Troubleshooting

Merge Conflicts

1. Update release branch from main
2. Resolve conflicts locally
3. Push resolved version
4. Retry finalization

Failed Deployment

1. Check workflow logs
2. Verify build succeeds locally
3. Check Azure SWA status
4. Rollback if necessary

Missing Changes

1. Verify commits are on release branch
2. Check if files are in .gitignore
3. Review build output

Next Steps

• Deployment — Deployment workflows
• Development Requests — Automated changes
• GitHub Setup — Repository configuration