Skip to main content

Change Management Policy

Introduction​

WeSalute Change Management Policy describes how changes to the WeSalute system are proposed, reviewed, deployed, and managed. This policy covers all changes made to the WeSalute software, regardless of their size, scope, or potential impact. This policy is designed to mitigate the risks of:

  • corrupted or destroyed information

  • degraded or disrupted computer performance

  • productivity losses

  • introduction of new vulnerabilities, configuration errors and software bugs in infrastructure and code

  • exposure to reputation risk

Version Control​

All of our software is version controlled and synced between contributors (developers). Access to the central repository is restricted based on a Team Member's role. Using a decentralized version control system allows multiple developers to work simultaneously on features, bugs, fixes, and new releases; it also allows each developer to work on their own local code branches in a local environment. All code is written, tested, and saved in a local repository before being synced to the origin repository. Writing code locally decouples the developer from the production version of our code base and insulates us from accidental code changes that could affect our users. In addition, any changes involving the persistence layer (database) are performed locally when developing new code, where errors or bugs can be spotted before the change is deployed to users.

Branching Model​

Best Practices

We use GitFlow!

Production Branch​

The v<version-major>.<version-minor>.<version-hotfix> branch reflects the current state of the application in production.

Staging Branch​

The develop branch reflects the current stage of the application(s) on the staging server(s).

Development Branch​

The release/<version-major>.<version-minor> branch reflects the development changes delivered most recently for the next release.

As for the next release branch (release/<version-major>.<version-minor>), it would be deployed on staging for UAT purposes. Once a release is out, staging can switch back to master.

Feature Branches​

Feature branches are used to develop new features for a future release, the specifics of which might not be known when development starts. A given feature branch will exist as long as the feature is in development; the branch will eventually either be merged back into develop, to add the new feature to an upcoming release with a pull request, or discarded (if the feature will not be added to an upcoming release).

Feature branches may branch off from and must merge back into develop. They typically exist in developer repos only, not in origin.

Security Bugs​

WeSalute recognizes that security bugs represent key issues that should be resolved quickly to maintain the security, confidentiality, privacy, processing integrity, and availability of the service. WeSalute commits to resolving security bugs within reasonable timelines as outlined by company procedural commitments in Vanta.

Hotfix Branches​

Hotfix branches are meant for new, unplanned production releases that address the live system being in an undesired state. A hotfix branch is made off of the master branch, with the latest production version, when a critical production bug must be resolved. This allows team members on the master branch to continue their work while someone else prepares the bugfix. When finished, the bugfix needs to be merged back into the original branch, so it is deployed to production. The merge should be done through a pull request. Hotfixes that are merged directly into master, without going through master, are exceptions that should be used only when a critical bug in the production system needs to be addressed immediately. Permission for a hotfix should be obtained from EngineeringOps leadership and should be noted in the pull request.

Change Initiation​

To initiate a change, the developer first creates a feature branch on his or her local machine. Code changes are grouped into diffs, each of which represents a proposed change to the codebase.

Pull Requests​

When a developer finishes a feature branch, they make a pull request to merge those changes into master. This submits the changes for peer review. For all code changes, the reviewer should be dierent from the author. Pull requests allow developers to describe the changes they're making; co-workers can review the set of changes in a code review. Pull requests also trigger automated testing and code-quality checks that must be completed and returned successfully before merging is allowed. Testing and approval are logged by the system. A pull request's details section should be used to note any non-code changes (e.g. environment or database changes) needed before the commits are merged.Once tests pass and the code is approved, the author can merge the code to the central repository.

Merging a Pull Request​

Before merging a pull request, the developer should check that all prerequisites have been met, including environment changes or database migrations. Once non-code changes have been implemented, the pull request can be merged. If the application is deployed through our standard, zero-downtime development process, the developer's job is complete. If any of these changes necessitate system down-time, the merge should take place within a scheduled and pre-announced window when customers are less likely to be affected.

Code Reviews, Change Review, and Change Approval​

Before the feature branch is merged, a code review should be performed. Code reviews are performed by a second developer (i.e. not the one who wrote the code), who considers questions like:

  • Are there any obvious logic errors in the code?

  • Are all cases specified in the requirements fully implemented?

  • Is there sufficient automated testing for the new code? Do existing automated tests need to be rewritten to account for code changes?

  • Does the new code conform to existing style guidelines?

  • Are there any egregious security errors as dened by the OWASP Top 10?

A code review should take place after all code has been written and automated tests have been run and passed, as this ensures the reviewer's time is spent checking what automation misses.

The reviewer should note all potential issues with the code; it is the responsibility of the author(s) to address those issues or explain why they are not applicable.

Once the review process finishes, each reviewer should leave a comment on the pull request confirming the change is accepted and approve the entire pull request. Only when the pull request is accepted may the original author(s) may merge their change into the release branch.

Automated Testing​

When a pull request is initiated, our automated test suite is triggered to run against the new code.

Deployment​

The system is monitored on a continuous basis. Should the site be negatively affected by a change, that code change is rolled back.

Zero Downtime Deployment​

Zero-downtime departments allow us to make changes without waiting and allow us to return the application to a previous state easily.

Requesting Non-Code Configuration Changes​

Outside of code all configuration changes must be required via the WeSalute Help Center. Change Requests are reviewed, approved, and have an SLA associated with them.

Disciplinary Action​

Team Members who violate this policy may face disciplinary consequences in proportion to their violation. WeSalute ExecutiveOps will determine how serious an Team Member's offense is and take the appropriate action.

Other Helpful Information​

Policy Review, Disciplinary, & Responsibility​

Responsibility​

The CTO is responsible for ensuring this policy is followed.

warning

This Policy currently does not have the required policy footer content standard on WeSalute Policies. This may be intentional by the nature of the content.