victoria-gwemail-rebuilder 0.0.2

Victoria Plugin that allows the creation and DESTRUCTION of Glasswall Email on the cloud.

Victoria GWEmail Rebuilder

Victoria Rebuilder is a V.I.C.T.O.R.I.A is a plugin that allows you to run multiple Azure DevOps release pipelines

Features

• Run a series of release pipelines based on a stages most recent successful releases in Azure DevOps
• Run a series of release pipelines for a stage based off another stage's most recent successful releases in Azure DevOps

User guide

Prerequisites

• Python 3.9
• Pip
• Victoria

Installation

$ pip install -U victoria_rebuilder

Operation

Configuration

There is an example configuration file provided, please update it as you see fit using the guidance below.

Access Configuration

access:
  access_token: <encoded>
  organisation: Organisation
  project: Azure DevOps Project
  email: [e-mail]

• access_token : The PAT token associated to the email and organisation. The PAT Token must have Read and Write access to Releases.
• organisation : The organisation in Azure DevOps.
• project : The project in Azure DevOps
• email : The email account associated to the PAT token.

Encrypting data for config values

In the config, the access_token which belongs to the access section should contain encrypted data. This can be achieved with the pre-build victoria encrypt command. Details on this can be found in the documentation:

1. Make sure you've set up your Victoria cloud encryption backend.
2. Paste the required value (i.e. the access_token) into the following Victoria command like:

   $ victoria encrypt data <access_token>
   

3. The command should output a YAML object containing fields data, iv, key and version. This is the encrypted value string and can be safely stored in config. Put this YAML object into your access section like:

   access:
      access_token:
        data: <snip>
        iv: <snip>
        key: <snip>
        version: <snip>
      organisation: Glasswall
      project: SomeProject
      email: [e-mail]
   

Deployment Configuration

deployments:
  stage: deploy_init_infrastructure
    releases:
      - name: Platform.Infrastructure
  stage: deploy_kubernetes_infrastructure
    releases:
      - name: Platform.Kubernetes

• stage : Name of the stage. The releases in each stage are all run first before the next stage is complete
• releases : List of releases and their name. The name is the name of the release in Azure DevOps

Help text

Usage: victoria rebuilder [OPTIONS] COMMAND [ARGS]...

  The rebuilder allows the destruction and rebuilding of environments via
  CLI.

Options:
  -h, --help  Show this message and exit.

Commands:
  copy     CLI call for rebuilding an environment based off another...
  optional flags:
      -r, ---resume     If you want the rebuilder to use the previous state file.

  rebuild  CLI call for rebuilding a specific kubernetes environment...
  optional flags:
      -r, ---resume     If you want the rebuilder to use the previous state file.
      -a, --auto-retry  If a release fails to deploy, instead of prompting the user 
                        for a y/n on retry, it automatically retries the deployment.

CLI Examples

Rebuild an environment

Rebuild is defined as running the release pipelines associated with the stage pent in this example.

victoria rebuilder rebuild pent

Copy an environment

Copy is defined as running the release for a stage based of an other stage. The use case for this is if you created a new stage and want it to have the same release version as the dev stage.

python rebuilder copy qa pent perf

Would copy the status of qa to pent and perf

Contribution

Bug reports

You can submit a bug report here.

Feature requests

You can request a new feature here.

Vulnerability reports

We prefer vulnerabilities to be reported in private so as to minimise their impact (so we can fix them before they are exploited!). To this end, please email any security vulnerability reports to '[e-mail]'. We would appreciate it if you use the issue template in the link below. All vulnerabilities will be acknowledged within one business day.

You can publicly report a security vulnerability here.

Pull requests

We accept pull requests! To contribute:

1. Pick up an unassigned issue from our issue board. Assign yourself to the issue so other people know you're working on it.
2. Work on your code in a feature branch that's got a descriptive name (like rework-fancy-integrator ).
3. Follow the Google style guide for Python. We use pylint to lint our code. We run pylint without the 'convention' and 'refactor' message classes. You can lint your code with: pipenv run pylint victoria_destroyer --disable="C,R" . We use yapf to automatically format our code. We recommend having it format the code whenever you save.
4. Make commits for each part of your pull request. Try not to make too many (if it's a small issue you may only need one). We try to use the imperative mood in commit message subjects.
5. To run tests locally and check coverage, use: pipenv run pytest tests/ --cov=victoria_rebuilder .
6. When ready to merge, create a pull request from your branch into master.
7. Make sure you link your pull request to the issue(s) it addresses.
8. The CI build will run for your pull request. If it fails then it cannot be merged. Inspect the output, figure out why it failed, and fix the problem. The CI build will lint your code, run tests, and send coverage/code to SonarCloud.
9. Someone will review your pull request and suggest changes if necessary.
10. When everything is signed off, your pull request will be merged! Congrats.

Developer guide

Prerequisites

• Python 3.9
• Pipenv

Quick start

1. Clone this repo.
2. Run pipenv sync
3. You're good to go. You can run commands using the package inside a pipenv shell , and modify the code with your IDE.