Deployment process - NIAID-Data-Ecosystem/nde-strapi GitHub Wiki

The Strapi instance is deployed automatically to AWS using GitHub Actions.

๐ŸŒฑ Branch Overview

  • dev Used for internal development and testing. Changes here are reflected in the development environment. The development instance is intended primarily for testing major updates (such as version upgrades), it has a separate/isolated server and database.

  • main Represents the production-ready version. The staging and production environments share a Strapi application and database. Pushing to this branch triggers a deployment to the staging and production environments.

Updating content within the Strapi CMS

  • Adding or editing content entries (e.g., updating a description, adding a new item) does not require a rebuild of the Strapi server.
  • These changes can be made at any time via the Strapi admin and will appear immediately with no downtime. (See Deploying Content to the Portal)

Deployment Process -- Strapi

  • Modifying content types (e.g., adding a field, renaming a model property, creating a new schema type) requires a rebuild of the backend.
  • This causes temporary downtime (typically a few minutes) of the admin interface as the server rebuilds and redeploys.

๐Ÿ“Note that the API will continue to work without interruption. Therefore, all portal instances will be unaffected by this type of deployment.

Development Environment

  • Push your changes to the dev branch.
  • This automatically triggers a GitHub Action that updates the dev Strapi instance.
  • The admin interface will have a few minutes of downtime, then the changes should appear.

Staging & Production Environments

  • Push your changes to the main branch.
  • This triggers the GitHub Action to rebuild and deploy to both staging and production.
  • The admin interface will have a few minutes of downtime, then the changes should appear.

โš ๏ธ Important Considerations

  • Downtime Risk: Since schema changes require a rebuild, expect temporary downtime of the admin interface during deployment. There will be no downtime for the API.
  • Coordinate with Server Team: If there is any confusion about production updates, please check in with the server team to ensure safe rollout and visibility.
  • API routes and permissions : When adding new API routes or users, you will need to apply the necessary permissions in the admin panel for them to be publicly available. This needs to be done in each admin interface, since they do not share a database. See information about API Routes Permissions.

Deployment Process -- Portal

For most content managed in Strapi, updates made through the CMS are reflected automatically in the portal without requiring code changes or manual re-deployment.

๐Ÿ”„ When a Portal Rebuild is Required

New Routes

If your content update adds a new page or route in the NIAID Data Ecosystem Portal - such as creating a new dynamic page (e.g.docs/new-route) - you must trigger a portal rebuild to generate the new route.

Example: Adding a documentation page titled "Help" with the slug /docs/help, requires initiating a portal rebuild. This process ensures that the route is statically generated and becomes accessible on the live site.

โœ… No code changes are needed - just the rebuild.

Additional information about dynamic routing in Next.js can be found here.

Steps to re-build:

  1. Navigate to the GitHub Actions tab in the NIAID Data Ecosystem Portal repository. Find the most recent deployment for the branch where you want the routes to be built. Example below uses the production branch.

image

  1. Click on re-run all jobs.

image