About Fleetwise PVBS
      Back to home
      1. Knowledge Base
      2. About Fleetwise PVBS

      Fleetwise Change and Release Management

      Change Management

      Fleetwise projects are managed on Azure DevOps Project, this gives us visibility on all past, in progress, and planned features.

      The lifecycle of a requested feature from scoping and design to deployment is as follows:

      • The product owner raise a ticket in DevOps Project with the details on the requested feature.
      • The ticket is discussed with the development team and estimated.
      • Once the estimate has been provided and approved, the ticket is then prioritised and to be commenced. 
      • During development, the ticket is assigned an 'In progress' status, the development team makes the required code changes, updating the ticket as they go. Any questions are raised as comments within the ticket to keep interested parties apprised of the progress.
      • Once the feature has been built, it is reviewed internally. Then it is assigned a "Testing" status and assigned back to the product owner.
      • Once the product owner has reviewed and approved the feature, the code change can be merged into the Staging code branch and deployed to the Staging instance.
      • Once tested in Staging, the ticket is assigned a "Release ready' status and is to be deployed on the deployment cycle.
      • When several new features are ready for deployment, a deployment ticket will be raised, with a target date planned. This ticket goes through a similar process as an individual feature ticket, but the focus is put on confirming that all PVBS functionality is working correctly in Staging.
      • Prior to deployment, a system release note will be sent to all clients' key contacts highlighter the content of the deployment.

      Release Management

      Branching Strategy

      The PVBS codebase uses a Develop > Staging > Master branching strategy.

      • A new feature is developed in a discrete /feature branch, then merged into the Develop branch once completed and reviewed.
      • A PR is then raised to merge Develop into Staging. This PR must be approved by a member of the PR Approvers team.
      • A PR is then raised to merge Staging into Master. This PR must be approved by a member of the PR Approvers team.

      CI/CD

      Merging into the Staging and Master branches triggers a build. Once the build has been successfully completed, a release pipeline instance is created automatically.

      • In the case of a Staging merge, this is automatically deployed to the Staging instances.
      • In the case of a Master merge, the pipeline is prepared, but must be manually deployed by a member of the Release Approvers team.

      Deployment Slots

      Each PVBS instance actually includes two App Service resources.
      • Live slot
      • Deployment slot
      When a release occurs, we deploy the latest build to the deploy slot, boot it, then swap the Live and Deployment slots. This has several advantages over the conventional deployment process, where the site is shut down, deployed, then rebooted.
      • Deployments are seamless from a user’s perspective. As the swap only involves redirecting traffic from one app service to another, there is no downtime required to deploy to production.
      • Deployments can be smaller, and occur more regularly. 
      • The previous working code build still exists on the deployment slot. In the event of a deployment failure, we can immediately swap the slots back.