Overview

This page describes a standard workflow for planning, developing, testing, reviewing, and releasing software changes.

1. Plan the change

Before implementation:

1. Understand the business or technical requirement.
2. Confirm the expected behavior and acceptance criteria.
3. Identify dependencies, risks, and affected systems.
4. Estimate the work and agree on priorities.
5. Create or update the relevant work item.

Large or high-risk changes should include a short technical design before development begins.

2. Create a development branch

Create a separate branch for the change using the team’s agreed naming convention. Branch names should clearly identify the work item or purpose.

Examples:

• feature/user-profile
• bugfix/invalid-login-validation
• hotfix/payment-timeout

Do not commit directly to the main or production branch unless the project process explicitly allows it.

3. Implement the change

During development:

• Follow the project’s coding standards.
• Keep changes focused and easy to review.
• Reuse existing components where appropriate.
• Validate input at system boundaries.
• Handle errors without exposing sensitive information.
• Add or update automated tests.
• Update documentation when behavior or configuration changes.

Avoid mixing unrelated refactoring with a feature or bug fix unless it is required for the change.

4. Test locally

Before opening a pull request, perform the relevant checks:

• Build or compile the application.
• Run unit tests.
• Run integration tests where applicable.
• Check formatting and static analysis.
• Test expected and unexpected inputs.
• Verify logging and error handling.
• Confirm that configuration changes work in a clean environment.

5. Code review

A pull request should include:

• A clear summary of the change
• The reason for the change
• Testing performed
• Known limitations or risks
• Screenshots or logs when useful
• Links to related work items

Reviewers should assess correctness, security, maintainability, performance, test coverage, and backward compatibility.

6. Release the change

After approval:

1. Merge the change using the project’s agreed strategy.
2. Allow the CI/CD pipeline to complete.
3. Deploy to the appropriate test or staging environment.
4. Perform smoke testing.
5. Deploy to production according to the release process.
6. Monitor logs, metrics, and alerts after deployment.

If a deployment causes unexpected behavior, follow the rollback or incident response procedure.

Definition of done

A change is complete when:

• The implementation meets the acceptance criteria.
• Automated tests pass.
• Code review is complete.
• Security and dependency checks pass.
• Documentation is updated.
• The change has been deployed or is ready for the approved release process.