[MAGNOLIA-8059] LightModule resources distribution: Define a convenient best practice Created: 25/Jan/16 Updated: 15/Apr/21 |
|
| Status: | Accepted |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Story | Priority: | Major |
| Reporter: | Christian Ringele | Assignee: | Christopher Zimmermann |
| Resolution: | Unresolved | Votes: | 3 |
| Labels: | collector-0cf1239d, discuss-in-pm, light-development | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | |||
| Issue Links: |
|
||||
| Template: |
|
||||
| Acceptance criteria: |
Empty
|
||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||
| Date of First Response: | |||||
| Description |
|
Using light module development approach for front end leaves a couple of questions open in regards of: How to use it and distribute changes on life systems. A main problems I see is:
My suggestion:
What it solves / advantages:
I see the chance of defining a convenient approach which can be easily be understood and sold. |
| Comments |
| Comment by Christopher Zimmermann [ 04/Feb/16 ] |
|
I like this suggestion. We've been very focussed on the developer experience, and have made massive improvements. But currently teams are rather on their own when it comes to pushing their changes to the public instances. I'd like them to have the freedom to use a git deployment approach - but I think this suggestion is a good default for people who "want magnolia to do the work for them". Also the set that gets pushed could actually be a combination of the active mix of resources on the author - including classpath/file/jcr hotfix. This problem was also brought up by a client (runger): |
| Comment by Brian Warrick [ 04/Feb/16 ] |
|
I believe it was nbarbe who helped Atlassian build a git connector to pull in resources (primarily css for them, I think). The question of deploying updates for templates and css comes up with many US customers. Ultimately, they like the flexibility to hotfix items, but they recognize that allowing production updates that do not go through some form of testing and source code management is risky. |
| Comment by Magnolia International [ 04/Feb/16 ] |
|
The approach described here has the advantage to be fully independent of the infrastructure and architecture since it is managed 100% by Magnolia. The location of the public and author instance, the way it is deployed and operated does not matter. It clearly reduces the operation cost. I personally prefer letting the infrastructure managing the distribution of the lightmodule resources. It is true that it will require additional work for the customer to setup this distribution. But I see more advantage in keeping things simple: Git + ssh already solved this problem quite easily and in a secured and standard way. It also enables a lot of possible scenarios like having an instance on a specific development branch only. A simple "git checkout" is enough, which is fully integrated in all devops tools, and this is the beauty! So I'm not saying that my idea is better, actually both are totally valid and fulfill needs of different users. |
| Comment by Christian Ringele [ 10/Feb/16 ] |
|
Regarding the company's using the "pure" FS & git way: If I think about it in production mode, there comes one big question most directly ask first place: Meaning: Where the activation has one big advantage: I'm not saying, that the FS approach should not be allowed. |
| Comment by Christian Ringele [ 14/Dec/16 ] |
A last coment here form my side, cause I think my suggestion is not fully understood: I talk about HOW the resources get from the author to the public. What is the gain that all instances have to pull at the same time? I don't see any. |
| Comment by Richard Unger [ 09/Nov/17 ] |
|
+1 from me (us at LFRZ) We can't easily deploy via GIT due to security policies, and we don't like the fact that we can't activate the resources. We currently solve this by using webdav to copy our light modules into JCR resources storage on the author systems, and activate them from there. We would love to see a more unified approach as described above. |
| Comment by Viet Nguyen [ 10/Nov/17 ] |
|
Ok also from SUPPORT-8104:
|
| Comment by Vivian Steller [ 22/Mar/19 ] |
|
Approach 1: JCR Publishing: +1 but with solution for * (see below) Approach 2: for SSH/Git: -1 reasons Other approaches: Approach 3: Resources dir in NFS *: +/-0 Approach 4: Command to download bundle/package from somewhere (Nexus, NPM) *: +2
Problem * All the approaches suffer from the following problem: regardless the fact that publishing is transactional, reloading definitions on public is not "transactional"; at least if you have many files/folders in your resources folder, scanning / reloading light modules takes some seconds. If in that particular moment user requests to pages/components using these definitions arrive, (Freemarker) exceptions will be thrown. I see two ways to solve this - very important - issue: |