Skip to content

Release Process (legacy ADO)

Step-by-step procedure for releasing to production.

Release Schedule

Release TypeFrequencyDay
RegularBi-weeklyTuesday
HotfixAs neededAny day

Pre-Release (T-2 Days)

Code Freeze

  1. Announce code freeze on develop
  2. Merge final approved PRs
  3. Create release branch: release/1.3.X

Release Notes

  1. Compile list of changes
  2. Document breaking changes
  3. Note configuration changes
  4. Create release notes document

UAT Sign-off

  1. Deploy to UAT environment
  2. Notify QA team
  3. Execute test plan
  4. 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

Terminal window
# Trigger manual backup
# Azure Portal → SQL Database → Export

Step 2: Deploy to Production

  1. Go to Azure DevOps → Pipelines
  2. Find “HISD-Production-Deploy”
  3. Select release branch
  4. Request approval
  5. Execute deployment
  6. Monitor pipeline

Step 3: Database Migration

Migrations run automatically. Verify:

  1. Check DbUpgrader logs
  2. Verify new scripts applied
  3. 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

  1. Watch Application Insights (30 min)
  2. Check error rates
  3. Monitor performance
  4. 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:

  1. Check that the service is running on the target VM
  2. Verify job execution in the logs
  3. 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

  1. DB Upgrader Task Failed — Check which migration script failed and why. Inform the Teams channel and take appropriate action.
  2. 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 saesharsopsfiletransfer storage → FileShares → jobscheduler → VM → PRODJOB
    • If the ZIP is present but not picked up, log into VM-JOBSCHEDULER-PROD and manually run the Windows Task
    • Check C:\HISD\PRODJOB\Release for 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):

  1. Run on Deployment Group — Targets VMs tagged with env_training
  2. AddConfigBuildersForJob — PowerShell task that adds configBuilders="AzureKeyVault" to appSettings and connectionStrings in the Job Scheduler config
  3. Replace Tokens — Replaces environment-specific tokens in EsharsJobScheduler.exe.config
  4. Deploy Windows Service — Deploys to C:\HISD\Training\Release\EsharsJobScheduler.exe with service name eshars-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

  1. Announce rollback

    • Notify stakeholders
    • Create incident channel
  2. 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
  3. Database rollback (if needed)

    • Point-in-time restore
    • Or apply rollback migrations
  4. Verify rollback

    • Smoke test
    • Monitor errors
  5. Post-mortem

    • Document what went wrong
    • Create fix for next release

Hotfix Process

For critical production issues:

Step 1: Create Hotfix Branch

Terminal window
git checkout main
git pull origin main
git checkout -b hotfix/issue-description

Step 2: Implement Fix

  1. Make minimal changes
  2. Write regression test
  3. PR with expedited review

Step 3: Deploy

  1. Merge to main
  2. Deploy to production (follow normal steps)
  3. 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.com

Follow this process for every production release.