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.

Deploying content updated within the Strapi CMS

  • Adding or editing content entries (e.g., updating a description, adding a new item) does not trigger a rebuild.
  • 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

  • Modifying content types (e.g., adding a field, renaming a model property) does trigger a rebuild of the backend.
  • This causes temporary downtime (typically a few minutes) as the server rebuilds and redeploys.

Development Environment

  • Push your changes to the dev branch.
  • This automatically triggers a GitHub Action that updates the dev Strapi instance.

Staging & Production Environments

  • Push your changes to the main branch.
  • This triggers the GitHub Action to rebuild and deploy to both staging and production.

⚠️ Important Considerations

  • Downtime Risk: Since schema changes require a rebuild, expect temporary downtime during deployment.
  • Use Backup DB (Optional): If uninterrupted access is needed during deployment, consider pointing the staging/production instances to a backup database during the transition.
  • Coordinate with Server Team: For production updates, check in with the server team to ensure safe rollout and visibility.

Deploying content to the portal

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

🔄 When a Portal Rebuild is Required

If your content update involves the creation of a new route in the NIAID Data Ecosystem Portal - such as adding a new dynamic page (ex: documentation page docs/new-route) - you will need to trigger a portal rebuild to generate the new route.

Example

If you add a documentation page titled "Help" with the slug /docs/help, you must initiate a rebuild of the portal. This 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 NIAID Data Ecosystem Portal Github Actions tab. Find the last deployment on the desired branch. image

  2. Click on re-run all jobs. image