Skip to content
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

Manage software factory environment deployment #131

Open
3 of 4 tasks
clarsonneur opened this issue Mar 23, 2018 · 1 comment
Open
3 of 4 tasks

Manage software factory environment deployment #131

clarsonneur opened this issue Mar 23, 2018 · 1 comment
Assignees
Milestone

Comments

@clarsonneur
Copy link
Collaborator

clarsonneur commented Mar 23, 2018

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:

  1. Run Pipeline to deploy to DEV - Considered as unstable but deployable
  2. Then run Pipeline to deploy to TEST - Considered as deployable and stable to become release candidate
  3. 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.

Ex:

Master Forjfile:

deployment:
  - dev:
  - test:
  - prod:
applications:
  - github:
    [...]
  - jenkins:
    [...]
  - vault:
    [...]
repositories:
[...]

dev Forjfile in deployments/dev/Forjfile:

applications:
  - github:
    token: '@vault://path/to/token/cred'
  - jenkins:
    deploy_to: aws
    aws_creds_data: '@vault://path/to/aws/dev/cred'
repositories:
  - test_repo:
    [...]

prod Forjfile in deployments/prod/Forjfile:

applications:
  - github:
    token: '@vault://path/to/token/cred'
  - jenkins:
    deploy_to: aws
    aws_creds_data: '@vault://path/to/aws/prod/cred'
repositories:
  - prod_repo1:
[...]

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
@clarsonneur
Copy link
Collaborator Author

clarsonneur commented Jul 21, 2018

Most of the code has been implemented.

So, last thing is about forjj pipelines

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

No branches or pull requests

1 participant