Skip to content

Ideas for abstraction of build + deploy workflow #5

Description

@pitou

We can abstract the workflow currently used by Anonymizer, these are some steps for an ideal roadmap:

Tests in CI

  • Use a Docker container for tests run on the CI (the container should be created from a Docker image which is identical to the production one)

Image build

  • Create a new base Docker image containing node, git, bash and other basic dependencies (edit: done)
  • Build time env vars depending on environment (production, staging...), e.g. Dockerfile path, Docker registry url, Docker image repo, deploy hook, and so on
  • Make deploy optional on CI workflow (how to express the condition?)

Deploy and app restart

  • Use deployer as container (pulls ad image that contains the updated version of the docker-compose.yml)
  • Docker credentials (for server login) as env var
  • (optional) Notify success/failure of build or deploy process (via Slack, email, etc.)

App execution

  • Read environment variables from an internal DB, exposed via a service
  • Use Nginx as container (like in Luca's proof of concept)

Misc

  • (optional in workflow) Database backups
  • (optional in workflow) Database migrations (after deploy, should it be run from the CI or from a script inside the server?)

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions