# Development Workflow

This guide walks you through developing a feature from branch creation to integration and deployment readiness. It covers semantic naming, frequent pushes to origin, PR targets and policies, automated validation, and how to iterate until your changes meet acceptance criteria.

For each new piece of work, developers should create a new feature branch from the current release branch.

# Checkout the current release branch
git checkout release/2504

# Get the latest changes
git pull

# Create a new feature branch with semantic branch names
git checkout -b feat/user-authentication  # For a new feature
# OR
git checkout -b fix/login-timeout  # For a bug fix
# OR
git checkout -b docs/api-documentation  # For documentation changes

# Work on your user story and do your local testing
# Avoid using git add . - Add only the files that are ready to be pushed
git add README.md

# Create a useful commit message to share with the team. Using semantic commit messages
git commit -m "feat: Added user authentication with multi-factor support"

# Push the feature branch to remote
git push -u origin feat/user-authentication

Use the Best Practices guide for naming patterns and scope. Keep branches focused on a single task or tightly related changes to simplify review and reduce merge risk. See Best Practices.

Open a PR to dev when your changes are ready for integration testing beyond local. Targeting dev ensures your work runs through validation and shared environment checks before staging for release.

# Check status
git status

# Make sure all the files you want are staged
git add <specific-files>

# Push up to Azure DevOps
git push -u origin <feature-branch>

• Target branch: dev branch
• Source branch: your feature branch (e.g., feat/user-authentication)
• Title: Use semantic prefix with clear description (e.g., "feat: Implement multi-factor authentication")
• Description: Include details about changes and how to test for your reviewer
• Link the related work item(s) from the sprint

The PR triggers automatic validation:

• Build validation pipeline runs to verify linting issues, security concerns and unit tests
• Required reviewers are automatically added based on path filters
• Policy checks are displayed in the PR status

After a code review, approval and successful build, complete the PR:

• The changes will run in the pipeline to the dev environment

The dev environment is your playground to validate functionality and acceptance criteria. Continue iterating on the same feature branch and PR until stable.

When ready for qa, open a PR from your feature branch to the current release/ branch. After approval and merge, open a second PR from the release/ branch to the qa branch. If you need promotion to qa ahead of the release cut, add the infra team as approvers.

For comprehensive best practices and guidelines, see Best Practices.

For information on release management, see Release Management.