Page History
This concept page is to discuss the topics that are shared between ConfigByCode and ConfigByFile.
Motivation
From:Frontend Vision - Management Overview
A Fundamental Problem
It’s handy to work on things in admincentral - but it’s an inherent anti-pattern that changes made in adminCentral are not in your “project”.
It causes additional headaches & work:
You must make the same changes in your files (resources&templates). You might forget.
You must export changes to configuration to bootstraps. You might forget.
You must import bootstraps or reinstall modules. You might forget.
You must write module version handlers to handle the configuration changes on update.
You must write tests for the module version handlers.
The module version handlers and tests must be reviewed and qa’d.
- How can a team work together, and deal with version control on a "shared" configuration?
Also the workflow for configuration is completely different then that for code, which slows down productivity.
ConfigByFile vs ConfigByCode
We acknowledge that there are significant benefits for both of these approaches and therefore intend to implement both. Much of the underlying code & mechanisms will be used by both approaches.
Key Benefits
- ConfigByCode
- IDE support such as Autocomplete.
- More powerful configuration as it can be manipulated - for example configuration could be optional based on other conditions or configuration.
- ConfigByFile
- Javafree: Usable by non-java developers, and within javafree modules.
- Exportable from existing configurations in AdminCentral.
- Potential IDE support if we use an XML format via DTD's etc.
- Hierarchy is clearly visible as in treeview.
Implications
Moving to "Volatile Configuration" means that the repository does not store ALL of the information needed for the running website. So pushing a website from an author to publics must change to accomodate this. We should at least CONSIDER a mechanism to push Config stored in files or code from public to subscribing servers.
Considering implications of ConfigByX
Implications | Current: Config in AdminCentral | Proposal: ConfigByFile or ConfigByCode | |
---|---|---|---|
UI | See the entire running configuration. | Have multiple files (views) open. | |
Instant updates | Change the config of ANY module. Instantly see the impact. | Change only your module. Would need tooling to reload changed config file. | |
Version Control | Pain that you have to export (often forget) Bootstrap diff / merge are difficult to understand Pain to apply changes from others - import / reinstall. | Seamless, works like other files. | |
Module version updates MVH | Pain to write & test & review. | Not necessary. | |
Uninstall | No clean uninstall. | Uninstall would be easy because configuration of other modules was not overwritten. | |
Changing config of other modules | Yes. | Yes. You could create a file that overwrites the changes from other files. | |
Agile changes | Yes. | Would require additional changes to distribute files. But one could still edit the config tree directly. | |
Deployment | |||
Publishing | Would work. |
Alternative Approaches and benefits
- Volatile Configuration: The ConfigByX are loaded at startup and used for item definitions, but the repository is not written to.
- PRO: Whether I make changes to the bootstraps, or to the ConfigByX - it does not matter, the proper config is built when I startup.
- PRO: Whether I make changes to the bootstraps, or to the ConfigByX - it does not matter, the proper config is built when I startup.
- Writes to Repository: The ConfigByX are loaded at startup, and the repository nodes are overwritten with them.
- PRO: The JCR is still the single source of truth - and the only thing that needs to be activated.
- CON: Scenario: I have a configFile the writes to repo at startup, then I remove some nodes in the configFile - on next startup those deleted nodes would still be in the repo - dont see how system could understand to delete those nodes.
We plan on approach 1. All further comments are based on that plan.
How can we ensure that edits via an AdminCentral app are not overwritten by ConfigByX at startup?
- Handle it like Inplace Templating: An extra property on the changed node, "preserve=true" prevents the ConfigByX from overwriting that node.
- Or, all manual changes are actually written to yet another repository: "manualconfig".
- These changes are applied to the active configuration after ConfigByX runs.
- Benefit: With additional tooling: it would be easier for a user to see what manual changes should be merged back to files in source control.
Resources / References
- Configuration by Code: Original 5 arch notes & discussion: https://docs.google.com/document/d/13rqtHSlO9hp43ZMsjiGTPwViJBWbmlo3oERaz5lIdD8/edit#heading=h.8qo3tfbu4pb5
- Configuration by Code Concept: Configuration by code
- Partners weigh in on the topic: http://forum.magnolia-cms.com/forum/thread.html?threadId=dacbff3f-0ce9-4293-b8b2-b5c1843568b7
- Readable bootstrap files. See: Concept - Readable config files (Readable bootstrap files)
Notes
How would we migrate from Bootstraps to ConfigFiles?
- Should all bootstraps be converted to ConfigFiles?
- If they were - would there then be a difference between "load-once" vs "load-every-start" config files?
- What rules do we use to distinguish between things that should be "load-once" vs "load-every-start"?
- Or should ALL configuration be loaded every start? (And manual changes / customizations are a layer on top of that.)
Considering "Writes to Repository" approach
A way that we could combine "volatile configuration" with having all active configuration in the repository - so that it could be published from there. Bootstraps & MVH write to the "stored configuration", the repository as we know it now. On each startup, the "stored configuration" is copied to a new "active configuration" in the repository - and all of the ConfigByX are applied to it. This ensures that changes in ConfigFiles are never persisted.. they are totally volatile.