|
1 | | - |
2 | | - |
3 | 1 | # Envers |
4 | 2 |
|
5 | | -Envers is a tool for handling environment files (e.g. .env) for multiple kind of |
6 | | -environments with versioning |
7 | | - |
8 | | -- License: BSD 3 Clause |
9 | | -- Documentation: https://envers.github.io |
| 3 | +`Envers` is a command-line tool (CLI) designed to manage and version environment |
| 4 | +variables for different deployment stages such as staging, development, and |
| 5 | +production. It provides a secure and organized way to handle |
| 6 | +environment-specific configurations. |
10 | 7 |
|
11 | 8 | ## Features |
12 | 9 |
|
13 | | -- The security of our code: Bandit is a powerful tool that we use in our Python |
14 | | - project to ensure its security. This tool analyzes the code and detects |
15 | | - potential vulnerabilities. Some of the key features of Bandit are its ease of |
16 | | - use, its ability to integrate with other tools, and its support for multiple |
17 | | - Python versions. If you want to know about bandit you can check its |
18 | | - [documentation](https://bandit.readthedocs.io/en/latest/). |
19 | | - |
20 | | -- Finds unused code: [Vulture](https://github.com/jendrikseipp/vulture) is |
21 | | - useful for cleaning up and finding errors in large code bases in Python. |
22 | | - |
23 | | -- Complexity of functions and modules: We use |
24 | | - [McCabe](https://github.com/PyCQA/mccabe) to identify the complexity in our |
25 | | - Python code that may be difficult to maintain or understand. By identifying |
26 | | - complex code at the outset, we as developers can refactor it to make it easier |
27 | | - to maintain and understand. In summary, McCabe helps us to improve the quality |
28 | | - of our code and make it easier to maintain. If you would like to learn more |
29 | | - about McCabe and code complexity, you can visit |
30 | | - [McCabe - Code Complexity Checker](https://here-be-pythons.readthedocs.io/en/latest/python/mccabe.html). |
31 | | - This tool is included with [Flake8](https://flake8.pycqa.org/en/latest/). |
32 | | - |
33 | | -- TODO |
34 | | - |
35 | | -## Credits |
36 | | - |
37 | | -This package was created with Cookieninja and the |
38 | | -[osl-incubator/scicookie](https://github.com/osl-incubator/scicookie) project |
39 | | -template. |
| 10 | +- Encrypt environment variables: Creates encrypted files that store environment |
| 11 | + variables that can be safely stored in a git repository |
| 12 | +- Group-Based Configurations: Allows defining variables for different |
| 13 | + groups/profiles like prod, dev, etc. |
| 14 | +- File-Based Variable Definitions: Supports multiple environment files (.env) |
| 15 | + with specific variables for each file. |
| 16 | +- CLI-Driven: Provide CLI commands that helps to create drafts for environment |
| 17 | + variables and deploy it to encrypted files |
| 18 | +- Spec Management: Each release has a defined spec that applies to all |
| 19 | + groups/profiles within that release. |
| 20 | +- Environment File Generation: Enables generating .env files for specific |
| 21 | + versions and groups/profiles using commands. |
| 22 | + |
| 23 | +## Installation |
| 24 | + |
| 25 | +TBD |
| 26 | + |
| 27 | +## Usage |
| 28 | + |
| 29 | +Below are the initial subcommands for `envers`: |
| 30 | + |
| 31 | +- `envers init`: Initialize the `envers` environment. |
| 32 | +- `envers deploy <spec version number>`: Deploy a specific version from the spec |
| 33 | + file. |
| 34 | +- `envers draft <spec version number>`: Create a new version draft in the spec |
| 35 | + file. Some variants of this command: |
| 36 | + - `envers draft <spec version number> --from <previous spec version number>` |
| 37 | + - `envers draft <spec version number> --from-env .env` |
| 38 | +- `envers profile-set --profile <profile_name> --spec <version_number>`: Add new |
| 39 | + content. |
| 40 | +- `envers profile load --profile prod --spec <spec version>`: Load a specific |
| 41 | + environment profile to files |
| 42 | + |
| 43 | +`envers init` creates the spec file at `.envers/.specs.yaml`. |
| 44 | + |
| 45 | +`envers deploy` creates the file `.envers/.data.lock`. This file is |
| 46 | +auto-generated by `envers` command, and it is encrypted. |
| 47 | + |
| 48 | +The initial version of `./.envers/.specs.yaml` would look like this: |
| 49 | + |
| 50 | +```yaml |
| 51 | +version: 0.1 # the envers spec version |
| 52 | +releases: |
| 53 | +``` |
| 54 | +
|
| 55 | +As you can see, it doesn't have too much information. If you want to draft a new |
| 56 | +version, you can run the following command: |
| 57 | +
|
| 58 | +```bash |
| 59 | +$ envers draft 1.0 |
| 60 | +``` |
| 61 | + |
| 62 | +After this command, the `.envers/specs.yaml` file should look like this: |
| 63 | + |
| 64 | +```yaml |
| 65 | +version: 0.1 # the spec version |
| 66 | +releases: |
| 67 | + # placeholder: the version for the environment variables. |
| 68 | + # if the status is draft, feel free to change the version number |
| 69 | + 1.0: |
| 70 | + # status attribute is handled by command line, don't change it manually |
| 71 | + status: draft # options are: draft, cancelled, deployed |
| 72 | + # placeholder: update help with the real help text |
| 73 | + help: |
| 74 | + # placeholder: a list of available profiles (groups) for this version. |
| 75 | + # at least one profile is required for the deploying |
| 76 | + profiles: |
| 77 | + - base |
| 78 | + # define the spec for that version, this spec should be used for all |
| 79 | + # profiles (groups) inside this version |
| 80 | + spec: |
| 81 | + # define the env file or any other kind of environment file to be used, |
| 82 | + # for now it just has support for .env files |
| 83 | + files: |
| 84 | + # placeholder: change `.env` to the correct dotenv file relative path |
| 85 | + .env: |
| 86 | + type: dotenv # default |
| 87 | + # `vars` is a dictionary for the environment variables |
| 88 | + # this defines the variables and some metadata, but not the real |
| 89 | + # value, because it is just the definition of the spec. |
| 90 | + vars: |
| 91 | + # placeholder: ENV is just a variable name, replace it by your real |
| 92 | + # environment variable |
| 93 | + ENV: |
| 94 | + type: string # options are: string, int, bool, path |
| 95 | + default: dev # in the case that the variable is not defined |
| 96 | +``` |
| 97 | +
|
| 98 | +Now, you can deploy your first version of environment variables: |
| 99 | +
|
| 100 | +```bash |
| 101 | +$ envers deploy 1.0 |
| 102 | +``` |
| 103 | + |
| 104 | +When a version is deployed, it creates automatically all the new spec into the |
| 105 | +`.envers/data.lock`. |
| 106 | + |
| 107 | +All the variables for the each profile and spec version is stored into |
| 108 | +`.envers/data.lock`, and this file shouldn't be changed for any reason. |
| 109 | + |
| 110 | +Finally, we can create the environment variables for the `base` profile: |
| 111 | + |
| 112 | +```bash |
| 113 | +$ envers profile set --profile base --spec 1.0 |
| 114 | +``` |
| 115 | + |
| 116 | +`envers` will ask you via prompt the value for each variable defined in the spec |
| 117 | +for version `1.0`. |
| 118 | + |
| 119 | +## Roadmap |
| 120 | + |
| 121 | +- Detailed spec and content management functionalities. |
| 122 | +- Enhancements in versioning and group management. |
| 123 | +- Integration with makim and sugar. |
| 124 | + |
| 125 | +## Contributing |
| 126 | + |
| 127 | +https://osl-incubator.github.io/envers |
| 128 | + |
| 129 | +## License |
| 130 | + |
| 131 | +BSD-Clause 3 |
0 commit comments