Search…
GitOps
Description of ReleaseHub GitOps Workflow

Introduction to ReleaseHub GitOps

With Release you can use our UI to manage your application template, environment variable files and environment configurations. But, Release also supports managing these configuration files in your Git repository. If you have your code and it's Release configuration file within one branch, GitOps allows concise management and version control of these files. However, keep in mind that if you have multiple environments within the same branch, we advise that you use our UI. Because of Git's 'branch-based' workflow, GitOps is limited to one environment per branch. The requirements to use GitOps are:
  • GitOps must be enabled for your application, please contact [email protected] to enable it
  • You need to add these two lines to your .release.yaml file
    1
    application_template: .release/application_template.yaml
    2
    environment_variables: .release/environment_variables.yaml
    Copied!
  • You have these two files (application_template.yaml and environment_variables.yaml) checked-in to your .release directory.
Figure 1. Both configuration files in the .release directory
Once these three requirements are met you will be able to manage your Release configurations via Git.
In the same way you work on features and bugs in branches, you can try new configurations in branches and when you merge back to your main branch, your configuration changes will be included in your main branch. GitOps automatically pushes and deploys configuration changes to your Release environments.

Release Configuration Relationships

Figure 2. Simplified Release configuration relationships without environment variable configurations
When you create an application in Release we automatically create a default application template for you. Release also creates a default environment variables file which contains your application specifics once you modify it. Environment configurations are created by serializing the application template and environment variables file. There is no specific configuration for any environment stored in Gitops.
If you want to have different environments (say, staging and production with different replicas and CPUs etc.) coming from one master branch, we advise that you either create a separate branch for each environment, or use the Release UI and keep the one branch.
GitOps is enabled for your whole account by default. You can opt to enable GitOps per application and manage other applications using the UI.
Figure 3. Example of environments with different application templates as their parents
When you make changes to either the application template or environment variables file, a new environment configuration is created and deployed. With GitOps enabled, changes made to the configuration files are updated only from your repo and no longer from the Release UI. You could however set configuration immutable keys in the UI which GitOps would not be allowed to modify.
Whenever you modify and save the configurations, the environment's configuration version is incremented. The major number is based on the version of the Application Template and the minor number is the version of the Environment Configuration. The major number of the Environment Configuration never changes.
Whenever you save an Environment Configuration or Environment Variable file it increments the minor number.

GitOps Workflow

When using GitOps the creation of the specific Environment Configurations is done automatically via a webhook processor that follows the workflow below in Figure 4. Any time you push to your repository, Release runs this workflow to decide if it should create new templates and/or configs, and ultimately if it should deploy to any environments.
Figure 4. GitOps Flow Chart

Pseudocode for the GitOps Flow Chart

1
##check if the Release GitOps files are modified
2
if release_files_modified
3
4
#get the template from the repo
5
template_from_repo = app.template_from_repo
6
7
#loop through every app for this repo that matches the branch
8
repository.apps.with_branch(branch).each do |app|
9
10
##diff the template, if true, generate and save new templates
11
if diff(template_from_repo, app.previous_template)
12
generate_new_templates(app).save
13
end
14
end
15
16
#for every active environment for the repo that matches the branch
17
repository.active_environments.with_branch(branch).each do |env|
18
19
#transform app template to environment configuration
20
env_config = transform_app_template_to_env_config(env)
21
22
env_config.save
23
24
#if you want to deploy any matching envs, this setting must be true
25
if should_deploy_active_envs_that_track_branch_with_config_change?
26
deploy_env(env)
27
end
28
end
29
end
Copied!
On every push to your repository, Release checks to see if there are any changes to the Release GitOps files and reacts accordingly. GitOps allows you to have different environment configurations on different branches. These configurations and branches can then be merged back to your main branch. In the same way you can work on your code in branches, you can do the same with your application templates and environment variables.
Release will create new configurations for your environments, but will not overwrite these attributes : 'context', 'domain', 'hostnames'