New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DEPLOY-278: ADR for applying extensions #67

Merged
merged 4 commits into from Dec 19, 2017

Conversation

Projects
None yet
5 participants
@gavincornwell
Contributor

gavincornwell commented Dec 18, 2017

Added new ADR to explain decision of applying extensions at build time vs runtime.

DEPLOY-278 / DEPLOY-269: Deployment of the RM and Sync Services amps
Added new ADR to explain decision of applying extensions at build time vs runtime.
## Decision
We have two options, apply extensions at build time, thus retaining the immutability advantage or apply extensions at runtime as the container initializes, breaking immutability.

This comment has been minimized.

@rgauss

rgauss Dec 18, 2017

Member

We did discuss runtime options that wouldn't necessarily break immutability of the container, like using a volume.

Perhaps we should mention we've considered that approach?

This comment has been minimized.

@gavincornwell

gavincornwell Dec 18, 2017

Contributor

We can but I'd argue that is still breaking immutability as we're changing the behaviour of the image!?

This comment has been minimized.

@gavincornwell

gavincornwell Dec 18, 2017

Contributor

I've added a line to say we investigated volumes and initContainers.

Conversely, applying extensions at build time means we will be forcing customers to build their own images depending on which official and custom extensions they require.
Given the number of disadvantages to applying extensions at runtime, customers are already used to applying their own extensions and they're having to learn a new deployment mechanism anyway, we are selecting the build time option.

This comment has been minimized.

@rgauss

rgauss Dec 18, 2017

Member

I think everything in this section before this line should be moved to the Context section.

This comment has been minimized.

@gavincornwell

gavincornwell Dec 18, 2017

Contributor

Done.

As a company we will release a small number of images with and without common AMPs applied.
To mitigate the additional complexity for customers we will provide scripts and clear documentation on how to build their own images to meet their requirements.

This comment has been minimized.

@rgauss

rgauss Dec 18, 2017

Member

This should probably be moved to the Consequences section.

This comment has been minimized.

@gavincornwell

gavincornwell Dec 18, 2017

Contributor

Ha! I originally had it in Consequences and moved it ;-)

I've moved it back.

Conversely, applying extensions at build time means we will be forcing customers to build their own images depending on which official and custom extensions they require.
Given the number of disadvantages to applying extensions at runtime, customers are already used to applying their own extensions and they're having to learn a new deployment mechanism anyway, we are selecting the build time option.

This comment has been minimized.

@rgauss

rgauss Dec 18, 2017

Member

We should reword this sentence to start with "We will..."

This comment has been minimized.

@gavincornwell

gavincornwell Dec 18, 2017

Contributor

Done.

Alfresco allows the core product to the enhanced via external modules in the form of [AMPs](https://docs.alfresco.com/5.2/concepts/dev-extensions-packaging-techniques-amps.html) or [simple JARs](https://docs.alfresco.com/5.2/concepts/dev-extensions-packaging-techniques-jar-files.html).
This results in two big problems:
* How do we release containers with every combination of AMP available?

This comment has been minimized.

@rgauss

rgauss Dec 19, 2017

Member

We've been asked to not write ADRs with bullets or lists, the thought being that writing out full sentences forces one to think differently and add more detail.

This comment has been minimized.

@gavincornwell

gavincornwell Dec 19, 2017

Contributor

Fair enough, updated to remove them.

DEPLOY-278 / DEPLOY-269: Deployment of the RM and Sync Services amps
Removed bullets and numbered lists following PR feedback.
@rgauss

rgauss approved these changes Dec 19, 2017

@gavincornwell gavincornwell merged commit 2212806 into master Dec 19, 2017

@gavincornwell gavincornwell deleted the DEPLOY-269 branch Dec 19, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment