Skip to content

02_Flox Mini Workflow

Jump to bottom
David Wyss edited this page Aug 23, 2022 · 3 revisions

Minimal Development Workflow

NOTE: As of 23.08.22, the specific workflow for master merge -> live release has not been implemented yet. The other workflows can be achieved by cloning the Flox repository and either deleting or disabling the unneeded workflows (e.g. staging workflow), while keeping the needed workflows (e.g. auto-update deployment of dev, etc.). The live and dev systems must, analogous to the full Flox workflow, be set up through the corresponding manually triggered GitHub action.

Introduction

Flox includes two workflows: The standard workflow that is intended to be used on larger projects, and the mini workflow for small, lean projects that (usually) don't include a PM. This Page is about the minimal workflow.

Basics

It is recommended to use the following specified workflow only for the development of small-scale Flox projects.

The following diagram outlines the basic Flox mini-workflow:

This workflow assumes the existence of two long-lived systems: dev and live.

  • dev continuously mirrors the state of development, including all features that have been developed, but not yet validated. This system is accessed by developers and PMs (if applicable), as well as tested by customers before live releases.
  • live is a subset of the dev features, and includes only those that have gone through customer review. Additionally, releases to the live system are only done upon customer request. This system is accessed by customers and end users!

Usually, in order to keep running costs at a minimum, both systems should be running serverless (AWS Lambda for frontend & backend, AWS Aurora Serverless for database). However, upon customer request, it would also be possible to use e.g. a full EBS or ECS setup, which would increase performance at the price of higher running costs.

Releasing for Production

  1. Create a PR from dev to master
  2. Upon successful developer review, have the PM (if applicable) and customer test the features on the dev system.
  3. If both PM and customer are content, merge the PR to master to trigger an automatic deployment to the live system.

CAUTION: Only do this once the customer has approved the release, since there may be some downtime!

Clone this wiki locally