Page tree
Skip to end of metadata
Go to start of metadata

Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 121 rates

Implemented in 4.2

Official Documentation Available

This topic is now covered in Node builder API.

(!)see NodeBuilder API concept page - Writing and maintaining update tasks is a error-prone and also boring task.

The Problem

The main problem is that we have to maintain the installation and update procedure separately. While we implicitly test the installation process we rarely do that for the update tasks.

It is very easy:

  • to forget an update tasks
  • write them wrongly (based on wrong assumption)
  • write them not fain grained enough because it is time consuming

Potential Solutions

Use a builder API

It is in general a good idea to code deltas / initial configuration by using a content builder API.

see MAGNOLIA-2828@jira

A) Do not separate Installation /Update

  • write the initial installation process
  • on later installations 1.0.3 execute the initial installation and the deltas
  • on update simply execute the deltas (as today)

This works as long the deltas are small enough. But there is a tricky thing to consider: that each module executes the complete chain and only then the next modules update tasks are executed. This can lead to unwanted side effects if one delta depends on a former state from an other module.

B) Generate the delta code

We could have a tool which can generate the update code (using the builder API) based on either two repository states or two bootstrap files.

  • this ensures that nothing gets forgotten
  • tasks are fine grained
  • easier to verify
    (minus) it's too easy to make mistakes by relying too much on such a tool (i.e. the tool can't know if a property has been renamed ("template" / "templatePath") or dropped and another one was added (i.e if it should keep the value or not)
  • No labels

1 Comment

  1. Other areas that make these hard to write:

    • maintaining branches
    • erroneous or missing tasks, which we have to add after the fact, "healer tasks", are even harder to write properly, AND to maintain in branches.

    One other point to take into account is that, much like tests, it is easier to write the update tasks at the same time as the feature you're adding/modifying, rather than after the fact. And indeed, having a single "trail" (rather than 1) update bootstrap tasks 2) patch up for updates) would make this easier.