Staticman is architected with two configuration files:
A YAML-formatted "site/repo" file that is meant to be found in a git service (such as GitHub or GitLab).
A JSON-formatted "server" file (which may be overridden/supplemented using environmental variables).
With this architecture, multiple web sites (each with their own source git repository) may leverage a single "community" Staticman instance. Unfortunately, this architecture hinders the implementation of a more "robust" development lifecycle that features promotion through, for example, development, test, staging, and production environments.
For example, the schema for the YAML-formatted "site/repo" file currently requires that a value be set for the branch property and defaults to master. However, this precludes the ability for the YAML-formatted "site/repo" file to be promoted, without change, on the way to production. Similarly, with Staticman currently only allowing for Akismet to be enabled/disabled via the akismet.enabled property in the YAML-formatted "site/repo" file, Akismet cannot be cleanly disabled in dev or test (but remain enabled in prod) without requiring a modification to source code during code promotion.
In order to address this shortcoming, several properties should be added to the schema for the JSON-formatted "server" file, which could be shadowed by their YAML-formatted "site/repo" file counterparts:
akismet.enabled
branch
githubWebhookSecret
gitlabWebhookSecret
The goal would be to allow for any environment-specific configuration to be specified someplace other than the YAML-formatted "site/repo" file.
Once support for multiple environments is improved, a follow-on concern is cross-talk between tiers/layers of different environments. For example:
A dev site accidentally pointed at a prod Staticman instance.
A staging Staticman instance pointing at a prod Mailgun mailing list.
Webhooks triggered on a dev branch being processed by a prod Staticman instance.
In order to prevent/identify this cross-talk, logic checks should be added to the codebase. For example:
Verify that the branch specified in the webhook payload matches the value specified in the configuration(s).
Verify that the branch specified in the REST request matches the value specified in the configuration(s).
Verify that the origin request header sent to the entry endpoint matches one or more expected values.
Beyond preventative steps, the various artifacts generated by Staticman could be "tagged" with their source environment. For example:
Name and subject in notification emails.
Content and commit messages in pull/merge requests.
Address, name, and description in mailing lists.
This would make it obvious which notification emails, pull/merge requests, and mailing lists are aligned with which environments.
Staticman is architected with two configuration files:
With this architecture, multiple web sites (each with their own source git repository) may leverage a single "community" Staticman instance. Unfortunately, this architecture hinders the implementation of a more "robust" development lifecycle that features promotion through, for example, development, test, staging, and production environments.
For example, the schema for the YAML-formatted "site/repo" file currently requires that a value be set for the
branchproperty and defaults tomaster. However, this precludes the ability for the YAML-formatted "site/repo" file to be promoted, without change, on the way to production. Similarly, with Staticman currently only allowing for Akismet to be enabled/disabled via theakismet.enabledproperty in the YAML-formatted "site/repo" file, Akismet cannot be cleanly disabled in dev or test (but remain enabled in prod) without requiring a modification to source code during code promotion.In order to address this shortcoming, several properties should be added to the schema for the JSON-formatted "server" file, which could be shadowed by their YAML-formatted "site/repo" file counterparts:
akismet.enabledbranchgithubWebhookSecretgitlabWebhookSecretThe goal would be to allow for any environment-specific configuration to be specified someplace other than the YAML-formatted "site/repo" file.
Once support for multiple environments is improved, a follow-on concern is cross-talk between tiers/layers of different environments. For example:
In order to prevent/identify this cross-talk, logic checks should be added to the codebase. For example:
originrequest header sent to theentryendpoint matches one or more expected values.Beyond preventative steps, the various artifacts generated by Staticman could be "tagged" with their source environment. For example:
This would make it obvious which notification emails, pull/merge requests, and mailing lists are aligned with which environments.