You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Forjj Is deploying to docker on a unique environment. This is great to start learning on Forjj, but when we would like control what is deployed, we need to instroduce usual phase to control change stability, like any projects do.
As an example:
Run Pipeline to deploy to DEV - Considered as unstable but deployable
Then run Pipeline to deploy to TEST - Considered as deployable and stable to become release candidate
Then run Pipeline to deploy to PROD officially - Final official prod deployment.
Forjj deployment & Forjfile
This requires Forjj to manage those deployment information.
Actually, Forjj build and deploy from the same source repository.
And code is generated from template.
We need to split them to :
template source code - build job phase
Deployment source code - generated from templates by forjj update and used by forjj maintain to get secrets and additionnal parameters needed to do the deployment to the appropriate deployment environment.
Those deployment source code could be stored in a unique repository which could use the PR mechanism to really deploy, then webhook to run the deployment update. The code itslef could manipulate the github deployment feature to gain on this github capability.
Internally, Forjj should have a new section in the Forjfile, called deployments as show below:
deployment:
- dev:
- test:
- prod:
In the Forjfile template, this section is at the same level than applications and other section.
But at the end, will be split as follow:
Forjfile - master containing deployments section and all others sections.
deployments/<deployName>/Forjfile - Containing subset of master Forjfile, without `deployments, but with specific sections data regarding the deployment.
each deployments/<deployName>/Forjfile are specific to the environment that we want to deliver.
The split between master and deployment Forjfile is mainly a convention for source code management and lisibility.
We can have all in one Forjfile, but this would useful only in a Forjfile template to reproduce the software factory somewhere else.
Forjj credential
On Credential side, the deployment Forjfile file split proposed must be reproduced and required.
So internally, we should have the credential stored in split deployment directories as well.
plugins
Related to plugins, we should support the same deployment architecture.
Like Jenkins plugin:
The template source (which must be extracted) will be closed to forjj-jenkins.yaml
And the plugin should generate to another repository (docker mounted)
The forjj-jenkins.yaml should also support deployment in its structure.
GIT:
As soon as Jenkins or any others plugins will generate source code in another repo, Forjj should commit and push the result according to the flow used.
Usually, for all except prod deployment, we can consider a direct push to master, when the code is generated.
But on prod, we can/should introduce PR mechanism to validate the deployment and merge only when the deploy should occur.
I suggest to introduce a maintenance window which means that the deployment should be started only in the timeframe given and not when we merge the prod PR.
Tasks
Forjfile support for deploy env
Secrets support for deploy env
plugins supports
forjj pipeline
The text was updated successfully, but these errors were encountered:
User story
Forjj Is deploying to docker on a unique environment. This is great to start learning on Forjj, but when we would like control what is deployed, we need to instroduce usual phase to control change stability, like any projects do.
As an example:
Forjj deployment & Forjfile
This requires Forjj to manage those deployment information.
Actually, Forjj build and deploy from the same source repository.
And code is generated from template.
We need to split them to :
forjj update
and used byforjj maintain
to get secrets and additionnal parameters needed to do the deployment to the appropriate deployment environment.Those deployment source code could be stored in a unique repository which could use the PR mechanism to really deploy, then webhook to run the deployment update. The code itslef could manipulate the github deployment feature to gain on this github capability.
Internally, Forjj should have a new section in the Forjfile, called deployments as show below:
In the Forjfile template, this section is at the same level than applications and other section.
But at the end, will be split as follow:
deployments
section and all others sections.deployments/<deployName>/Forjfile
- Containing subset of master Forjfile, without `deployments, but with specific sections data regarding the deployment.each
deployments/<deployName>/Forjfile
are specific to the environment that we want to deliver.Ex:
Master Forjfile:
dev
Forjfile indeployments/dev/Forjfile
:prod
Forjfile indeployments/prod/Forjfile
:The split between master and deployment Forjfile is mainly a convention for source code management and lisibility.
We can have all in one Forjfile, but this would useful only in a Forjfile template to reproduce the software factory somewhere else.
Forjj credential
On Credential side, the deployment Forjfile file split proposed must be reproduced and required.
So internally, we should have the credential stored in split deployment directories as well.
plugins
Related to plugins, we should support the same deployment architecture.
Like Jenkins plugin:
The template source (which must be extracted) will be closed to
forjj-jenkins.yaml
And the plugin should generate to another repository (docker mounted)
The forjj-jenkins.yaml should also support deployment in its structure.
GIT:
As soon as Jenkins or any others plugins will generate source code in another repo, Forjj should commit and push the result according to the flow used.
Usually, for all except prod deployment, we can consider a direct push to master, when the code is generated.
But on prod, we can/should introduce PR mechanism to validate the deployment and merge only when the deploy should occur.
I suggest to introduce a maintenance window which means that the deployment should be started only in the timeframe given and not when we merge the prod PR.
Tasks
The text was updated successfully, but these errors were encountered: