As a developer I would like guidance on how to upgrade my pipeline when the bcdk has updated

[patricksimonian]

Summary

When the bcdk upgrades it could be for a number of reasons, dependency updates, new features added.. changes to images.

We should provide clear guidance on how to upgrade. There should be considerations that people may change their build, deploy and clean.js files. So we should prevent changing their scripts. In addition, if they have tailored their jenkins deploy/build configs we should prevent overwriting it.

Possible Outcome

A guide on upgrade instructions. My thinking is that when we make braking changes we should CLEARLY identify the changes and how to upgrade them manually as an operational task for the team. Automation is not necessary at this time.

[patricksimonian]

I have been doing some thinking on the best way to approach this.

Some of the issues are that if we upgrade our pipeline scripts (or add more best practices) we do not want to affect how developers may have customized their build/clean/deploy scripts.

This got me thinking that perhaps we provide Life Cycle or Plugin points that developers would integrate their customization into.

This design pattern is not new. It is used in tons of frameworks to allow customization.

For example:

A build workflow could be:

1. provide a plugin point to pass in templates and parameters
2. provide a plugin point pre build

   perhaps here a user wants to run some commands to post to rocketchat

3. provide a plugin point post build

   perhaps a user wants to interface with openshift

4. provide a plugin point post action

   perhaps a user wants to run some additional work loads or collect logs/stats

What does a plugin point manifest as?

Perhaps its just a simple module.export function

const rcApi = require('...')
module.exports.onPreBuild = async ({env, args}) => {
  await rcApi.postMessage('foo');

  return Promise.resolve();
} ...

I'm thinking in very simple terms of a front end app, I'd love to explore working with more stateful applications. Could this work for them too? I think so?

The notion of plugins would abstract away common workflow elements that are used in the pipeline cli. They would no longer need to know how their oc templates are processed and applied for example.

Thoughts @BcGovNeal @cvarjao @RajvirBains ?

[RajvirBains]

@patricksimonian, I agree with your suggestions, but my worry always is the overall effort for building something and then not getting much use out of it. Do we have a rough idea of how many people are using BCDK? I do think that with your approach there is a potential of attracting more users, which would be a big win.

[patricksimonian]

@RajvirBains I totally agree. It is something we are aware of. As far as not getting much use out of it, we do know now there are teams that are using best practices when working on the platform. There are teams halfway there and there are teams who are not at all. It would be ideal to be able to codify all these best practices and make it as easy as possible for teams to consume them (such as a Jenkins pipeline)

[patricksimonian]

Closing this issue as I don't think we will do signifanct work until there is better alignment between our team and others :)