Skip to content

Rethink dev - staging - production modes #106

@kapouer

Description

@kapouer

A site can be:

  • compiled (transpiled and bundled and minified)
  • hooked to git
  • frozen (webmaster cannot change blocks, maybe only inline blocks or href)
  • optimized (makes sense when frozen)
  • assigned to a domain (and exposing sitemap to robots) or not

The workflow for a site is:

  • debug: uncompiled, unfrozen, unoptimized, unassigned. Source is a git repo.
  • dev: compiled, unfrozen, unoptimized, unassigned
  • staging: compiled, frozen, optimized, unassigned
  • production: compiled, frozen, optimized, assign

dev -> staging or dev -> production should be done by first making a copy of the current site in dev mode.
This should be a "smart" copy that doesn't copy "uploads" folder of the dev site, since uplods are immutable
they can be shared between all modes.

Then staging -> production is done using the same "site".
This way one can continue to develop the site while having a production site running.

Optimizing regroups:

  • purge all unused elements (and their deps...)
  • purge css by crawling "all" pages
  • recompile all

Production versions are not necessarily erased - this way one can assign the domain to a previous production version.

git hooks should only apply to debug/dev mode.
In particular, git tags no longer do something specific (like update only production).
Only debug/dev mode shall allow reinstalling a site from git repository.

  • mysite.pageboard.io always points to development site.
  • mysite-commitish.pageboard.io points to a specific commit or tag of a staging copy.
  • mydomain.com points to mysite-commitish.pageboard.io (internally) which is a staging copy that became production.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions