🛠️
Wazimap technical handbook
  • Introduction
  • System Architecture
    • Database Models
    • IndicatorData
    • Geography Hierarchies
    • Choropleth Maps
    • Determine which instance to use
  • Development
    • Code Deployment
    • Component Architecture
    • Development Process
    • Pull Request Template Explanation
    • Code Review Process
    • Pull Request Template (FE)
    • Webflow Integration
    • Merging webflow exports
    • Rules for Webflow exports
    • Webflow exports & changelog
      • June 2023
      • March 2023
      • February 2023
      • December 2022
      • November 2022
      • October 2022
      • May 2022
      • April 2022
      • March 2022
      • January 2022
      • December 2021
      • November 2021
      • October 2021
    • Translation
    • Map components
  • Testing
    • Testing guidelines
    • Critical Paths
    • GUI Tests
    • Heroku Review Apps
  • Design
    • Iconography
  • Change Proposals
  • NGPx - Template
  • NGP1 - Changing the data model (Implemented)
  • NGP2 - Presenting Geographical Hierarchies to users
  • NGP3 - Change Geography Hierarchies
  • NGP4 - Format configuration
  • NGP5 - Multiple count columns
  • NGP6 - Profile-specific open graph metadata
  • NGP7 - Wazimap profile domain management
  • NGP8 - Replacing Webflow as frontend framework
  • Tutorials
    • Creating a new profile
    • Loading new geographies
    • Loading Data
    • Creating a new admin user
    • Creating a non-admin user for a private profile
    • Changing the Geography level name
    • Deployment to Dokku
  • Configuration
  • Profile Configuration
  • Profile Indicator Configuration
  • Profile Collection Configuration
  • Geographies, hierarchies and versions
  • API
    • General API Information
    • Upload API
    • Task Status
    • Point data API
Powered by GitBook
On this page

Was this helpful?

Export as PDF
  1. Development

Code Deployment

PreviousDetermine which instance to useNextComponent Architecture

Last updated 3 years ago

Was this helpful?

Frontend code merge

  1. Developer creates a draft PR

  2. Developer completes code and removes the draft label from the PR.

  3. The Trello ticket is moved from In progress to Code Review.

  4. The lead dev merges the latest staging into the PR and reviews. Once the code is ready, the PR is updated with the merged code.

  5. The Trello ticket is then moved into Review (Product Owner)

  6. The Product Owner reviews the Netlify deploy preview. Once the implementation is approved, the Trello ticket moves to To be deployed

  7. The Lead Developer merges the PR into staging

  8. The Product Owner reviews the staging server (on a scheduled, or ad hoc basis)

  9. Once approved, staging is merged into master which is then pushed to the production server.

This process allows to PO to review a feature before it is merged into the staging branch thereby removing the need to rollback a PR that isn't approved by the PO. One gap in this process if a bug enters the codebase during merging into staging. This can occur in the following cases:

  1. PR 1 is approved, PR 2 is approved, PR 1 is merged in staging, PR 2 is merged into staging. The PO has not had the opportunity to review PR 1 and PR 2 at the same time.

  2. Resolution of conflicts.