Release Process (legacy ADO)
Step-by-step procedure for releasing to production.
Release Schedule
| Release Type | Frequency | Day |
|---|---|---|
| Regular | Bi-weekly | Tuesday |
| Hotfix | As needed | Any day |
Pre-Release (T-2 Days)
Code Freeze
- Announce code freeze on
develop - Merge final approved PRs
- Create release branch:
release/1.3.X
Release Notes
- Compile list of changes
- Document breaking changes
- Note configuration changes
- Create release notes document
UAT Sign-off
- Deploy to UAT environment
- Notify QA team
- Execute test plan
- Get sign-off from product owner
Release Day Checklist
Pre-Deployment (T-2 Hours)
- Verify UAT sign-off received
- Confirm release notes complete
- Notify support team
- Announce maintenance window
- Verify rollback procedure
Deployment
Step 1: Pre-Deployment Backup
# Trigger manual backup# Azure Portal → SQL Database → ExportStep 2: Deploy to Production
- Go to Azure DevOps → Pipelines
- Find “HISD-Production-Deploy”
- Select release branch
- Request approval
- Execute deployment
- Monitor pipeline
Step 3: Database Migration
Migrations run automatically. Verify:
- Check DbUpgrader logs
- Verify new scripts applied
- Spot-check schema changes
Step 4: Smoke Test
- Login works
- Navigate to dashboard
- Create test visit (if safe)
- Check critical reports
- Verify background jobs running
Step 5: Monitor
- Watch Application Insights (30 min)
- Check error rates
- Monitor performance
- Review user feedback
Post-Deployment
- Announce deployment complete
- Update release tracking
- Merge release branch to main
- Tag release:
v1.3.X - Close related tickets
Post-Deployment Tasks
One-Time Database Scripts
Run any one-time migration scripts included in the release from the HISD/Eshars.DBUpgrader/SQL/APP/OneTimeRun directory.
Report Configuration
If new reports are deployed in this release, the pipeline publishes the RDLs automatically
(Step 10 of hisd-deploy-stage). For the full report deploy path — per-environment server
targets, manual/recovery publish, data-source setup, and the production permission-grants step —
see the dedicated Report (SSRS) Deployment runbook.
Job Scheduler Validation
Verify the Job Scheduler is running correctly after deployment:
- Check that the service is running on the target VM
- Verify job execution in the logs
- For troubleshooting, refer to:
TMHP Service Validation
Verify the TMHP Windows Service is running and processing files correctly.
eSHARS Functions
If there are Azure Functions included in this release, run the eshars-function release pipeline after all production deployment steps are completed.
Deployment Troubleshooting
Common Pipeline Failures
- DB Upgrader Task Failed — Check which migration script failed and why. Inform the Teams channel and take appropriate action.
- Job Scheduler Deployment Failed — If DB Upgrader succeeded but Job Scheduler failed, only rerun the Job Scheduler task:
- Check if the Azure DevOps task ran and pushed the Job Scheduler ZIP
- Verify the ZIP exists in
saesharsopsfiletransferstorage → FileShares → jobscheduler → VM → PRODJOB - If the ZIP is present but not picked up, log into
VM-JOBSCHEDULER-PRODand manually run the Windows Task - Check
C:\HISD\PRODJOB\Releasefor files with today’s timestamp - A VM restart may occasionally be needed
Training Environment: Job Scheduler Deployment
Training environment jobs have been migrated from Azure WebJobs to non-prod Job VMs for consistency with other environments.
The training release pipeline includes these tasks (in order):
- Run on Deployment Group — Targets VMs tagged with
env_training - AddConfigBuildersForJob — PowerShell task that adds
configBuilders="AzureKeyVault"toappSettingsandconnectionStringsin the Job Scheduler config - Replace Tokens — Replaces environment-specific tokens in
EsharsJobScheduler.exe.config - Deploy Windows Service — Deploys to
C:\HISD\Training\Release\EsharsJobScheduler.exewith service nameeshars-jobscheduler-training
Configuration is read from Azure Key Vault kv-eshars-training.
Rollback Procedure
When to Rollback
- Critical functionality broken
- Data corruption detected
- Performance severely degraded
Rollback Steps
-
Announce rollback
- Notify stakeholders
- Create incident channel
-
Restore previous version
Terminal window # Option A: Redeploy previous release# Azure DevOps → Previous successful deployment → Rerun# Option B: Swap deployment slots (if configured)# Azure Portal → App Service → Deployment slots → Swap -
Database rollback (if needed)
- Point-in-time restore
- Or apply rollback migrations
-
Verify rollback
- Smoke test
- Monitor errors
-
Post-mortem
- Document what went wrong
- Create fix for next release
Hotfix Process
For critical production issues:
Step 1: Create Hotfix Branch
git checkout maingit pull origin maingit checkout -b hotfix/issue-descriptionStep 2: Implement Fix
- Make minimal changes
- Write regression test
- PR with expedited review
Step 3: Deploy
- Merge to main
- Deploy to production (follow normal steps)
- Cherry-pick to develop
Version Numbering
Format: MAJOR.MINOR.PATCH
- MAJOR: Breaking changes, major features
- MINOR: New features, enhancements
- PATCH: Bug fixes, hotfixes
Example: 1.3.101
Communication Template
Pre-Release
Subject: [eSHARS] Scheduled Release - v1.3.X - [Date]
A new version of eSHARS will be deployed on [Date] at [Time] CT.
Expected downtime: ~15 minutes
Changes include:- [Change 1]- [Change 2]
Contact support@myeshars.com with questions.Post-Release
Subject: [eSHARS] Release Complete - v1.3.X
eSHARS v1.3.X has been successfully deployed.
Release notes: [link]
Report issues to support@myeshars.comFollow this process for every production release.