Page History
This concept page is to discuss the topics that are shared between ConfigByCode and ConfigByFile.
Purpose
From:Frontend Vision - Management Overview
A Fundamental Problem
It’s handy 1. It can be convenient 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?
2. Also the workflow for configuration is completely different then that for code, which slows down productivity.
3. Many developer are very efficient at working in their IDE - faster then in AdminCentral.
Analysis
ConfigByFile vs ConfigByCode
...
| 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. | What to publish? The ConfigFiles as well? Must you push new Jars? Could you publish the "active configuration"? |
Alternative Approaches and benefits
...
- 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
- Unconference Session on ConfigByX: Unconference 2014: ConfigByFile / ConfigByCode / Developer Sync Module
- Developers weigh in on the topic: http://forum.magnolia-cms.com/forum/thread.html?threadId=dacbff3f-0ce9-4293-b8b2-b5c1843568b7
- 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 codePartners 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 & bootstraps
...
Overview
Content Tools