LogoLogo
  • Welcome to Release
  • Getting started
    • Quickstart
    • Create an account
    • Prepare to use Release
    • Create an application
      • Create custom application
      • Create from template
      • Servers vs runnables
    • Create an environment
  • Guides and examples
    • Domains and DNS
      • Manage domains
      • DNS and nameservers
        • Configure GoDaddy
        • Configure Cloudflare
        • Configure Namecheap
        • Other DNS hosts
      • Routing traffic
    • Example applications
      • Full stack voting app
      • Flask and RDS counter app
      • Static site with Gatsby
      • Golang with Postgres and Nginx
      • WordPress with MySQL
      • Spring and PostgreSQL
      • Terraform and Flask
      • OpenTelemetry demo
      • Load balancer with hostname
      • Static JavaScript service
      • SSH bastion access to services
      • ngrok and OAuth for private tunnels
      • Using OAuth Proxy
      • Hybrid Docker and static site
      • App Imports: Connecting two applications
      • Example library
    • Running instances
      • Cron jobs
      • Jobs
      • Using Helm charts
      • Using terminal
      • Viewing logs
      • Troubleshooting
        • ImagePullBackoff error
        • CrashLoopBackoff error
        • Exit codes
        • OOM: out of memory
    • Advanced guides
      • Containers guide
      • Application guide
      • Kubernetes guide
      • Create a cluster
      • Upgrade a cluster
      • Managing node groups
      • Patch node groups
      • Hostnames and rules
      • Serve traffic on multiple ports
      • Configure access to your K8s cluster
      • Designing for multiple environments
      • Microservices architecture
      • Monitoring your clusters
      • Performance tuning
      • Visibility and monitoring
      • Working with data
        • Container-based data
        • Seeding and migration
        • Cloud-provided data
        • Golden images
        • Third party
      • Pausing Instant Datasets
        • Application pausing schedules
        • Pause/resume environments
      • Infrastructure as code
        • Terraform
  • Reference documentation
    • Account settings
      • Account info
      • Managing users
      • Build settings
        • Build arguments
        • Build SSH keys
      • Add integrations
      • View clusters and cloud integrations
      • Add datasets
      • Environment handles
    • Workflows in Release
      • Stages of workflows
      • Serial deployments
      • Parallel deployments
      • Rolling deployments
      • Rainbow deployments
    • Networking
      • Network architecture (AWS)
      • Network architecture (GCP)
      • Ingresses
      • IP addresses
      • Cloud-provided services
      • Third-party services
    • Release environment versioning
    • Application settings
      • Application Template
        • Schema definition
      • Default environment variables
      • GitHub
      • Pull requests
      • GitOps
      • Just-in-time file mounts
      • Primary App Link
      • Create application FAQ
      • App-level build arguments
      • Parameters
      • Workspaces
    • End-to-end testing
    • Environment settings
      • Environment configuration
      • Environment variables
        • Environment variable mappings
        • Secrets vaults
        • Using Secrets with GitOps
        • Kubernetes Secrets as environment variables
        • Managing legacy Release Secrets
    • Environment expiration
    • Environment presets
    • Instant datasets on AWS
    • Instant datasets on GCP
    • Instant dataset tasks
      • Tonic Cloud
      • Tonic On-Premise
    • Cloud resources
    • Static service deployment
    • Helm
      • Getting started
      • Version-controlled Helm charts
      • Open-source charts
      • Building Docker images
      • Ingress and networking
      • Configuration
    • GitOps
    • The .release.yaml file
    • Docker Compose conversion support
    • Reference examples
      • Adding and removing services
      • Managing service resources
      • Adding database containers to the Application Template
      • Stock Off-The-Shelf Examples
    • Release API
      • Account Authentication
      • Environments API
        • Create
        • Get
        • Setup
        • Patch
      • User Authentication
      • Environment Presets API
        • Get Environment Preset List
        • Get Environment Preset
        • Put Environment Preset
  • Background concepts
    • How Release works
  • Frequently asked questions
    • Release FAQ
    • AWS FAQ
    • Docker FAQ
    • JavaScript FAQ
  • Integrations
    • Integrations overview
      • Artifactory integration
      • Cloud integrations (AWS)
        • AWS guides
        • Grant access to AWS resources
        • AWS how to increase EIP quota
        • Control your EKS fleet with systems manager
        • Managing STS access
        • AWS Permissions Boundaries
        • Private ECR Repositories
        • Using an Existing AWS VPC
        • Using an Existing EKS Cluster
      • Docker Hub integration
      • LaunchDarkly integration
      • Private registries
      • Slack integration
      • Cloud integrations (GCP)
        • GCP Permissions Boundary
      • Datadog Agent
      • Doppler Secrets Manager
      • AWS Secrets Management
    • Source control integrations
      • GitHub
        • Pull request comments
        • Pull request labels
        • GitHub deployments
        • GitHub statuses
        • Remove GitHub integration
      • Bitbucket
      • GitLab
    • Monitoring and logging add-ons
      • Datadog
      • New Relic
      • ELK (Elasticsearch, Logstash, and Kibana)
  • Release Delivery
    • Create new customer integration
    • Delivery guide
    • Release to customer account access controls
    • Delivery FAQs
  • Release Instant Datasets
    • Introduction
    • Quickstart
    • Security
      • AWS Instant Dataset security
    • FAQ
    • API
  • CLI
    • Getting started
    • Installation
    • Configuration
    • CLI usage example
    • Remote development environments
    • Command reference
      • release accounts
        • release accounts list
        • release accounts select
      • release ai
        • release ai chat
        • release ai config-delete
        • release ai config-init
        • release ai config-select
        • release ai config-upsert
      • release apps
        • release apps list
        • release apps select
      • release auth
        • release auth login
        • release auth logout
      • release builds
        • release builds create
      • release clusters
        • release clusters exec
        • release clusters kubeconfig
        • release clusters shell
      • release datasets
        • release datasets list
        • release datasets refresh
      • release deploys
        • release deploys create
        • release deploys list
      • release development
        • release development logs
        • release development start
      • release environments
        • release environments config-get
        • release environments config-set
        • release environments create
        • release environments delete
        • release environments get
        • release environments list
        • release environments vars-get
      • release gitops
        • release gitops init
        • release gitops validate
      • release instances
        • release instances exec
        • release instances logs
        • release instances terminal
  • Release.ai
    • Release.ai Introduction
    • Getting Started
    • Release.ai Templates
    • Template Configuration Basics
    • Using GPU Resources
    • Custom Workflows
    • Fine Tuning LlamaX
    • Serving Inference
Powered by GitBook
On this page
  • Requirements
  • Release configuration relationships
  • Immutability, Updates, and Overrides
  • GitOps workflow
  • Pseudocode for the GitOps flow chart

Was this helpful?

  1. Reference documentation

GitOps

Description of Release GitOps workflow

PreviousConfigurationNextThe .release.yaml file

Last updated 1 year ago

Was this helpful?

You can use the Release UI to manage your Application Template, Environment Variables files, and environment configurations. But Release also supports managing these configuration files in your Git repository.

If your code and its Release configuration file are in the same branch of your Git repository, GitOps gives you concise management and version control of files.

Because of Git's branch-based workflow, GitOps is limited to one environment per branch.

  • If you'd like to have different environments (for example, staging and production environments with different resource allocation) coming from one master branch, we recommend you create a separate branch for each environment.

  • If you have multiple environments in the same branch, we recommend you use our UI.

Requirements

We strongly encourage you to integrate your GitOps workflow with our Release CLI. You can initialize the correct GitOps files and validate they are correct before merging, which is very highly recommended to avoid syntax errors and possible broken deployments.

In order to use GitOps with Release, you'll need to:

  • Contact support@release.com to enable GitOps for your account. GitOps is enabled for your whole account by default, but you can opt to enable GitOps per application and manage other applications using the Release UI.

  • We strongly encourage you to make sure you use secret references from one of our supported vaults.

  • Add these two lines to your .release.yaml file:

    application_template: .release/application_template.yaml
    environment_variables: .release/environment_variables.yaml
  • Check the application_template.yaml and environment_variables.yaml files in to your .release directory.

Release configuration relationships

Here's a simplified diagram of Release configuration relationships:

When you create an application, Release automatically creates a default Application Template and a default Environment Variables file. These files can be modified to include your application specifics.

Each time you create an environment for your application, Release will configure it using the Application Template and environment variables.

No configuration for any environment is stored in GitOps.

When you make changes to either the Application Template or the Environment Variables file, a new environment configuration is created and deployed.

Immutability, Updates, and Overrides

If you have GitOps enabled, any changes you make to the configuration files are only updated from your repo, and no longer from the Release UI. It is still possible to update the configurations manually, but the next push from your repository will override the manual updates. There are a few exceptions noted below.

Certain attributes cannot be updated with GitOps! Release will create new configurations for your environments, but the following attributes will not be overwritten: context, domain, hostnames, rules. These fields must be updated manually via the UI to prevent cross-environment changes during repository pushes.

You may have certain environment variables might likewise not want to be updated during the gitops workflow. You can exclude certain environment variables from being updated via GitOps (so they must also be manually edited via the UI) as shown in the following example:

---
mapping:
  SOURCE_VERSION: RELEASE_COMMIT_SHA
  API_URL_CLIENT: WEB_INGRESS_URL
gitops:
  immutable_keys:
  - ENVIRONMENT
  - REDIS_URI
defaults:
- key: ENVIRONMENT
  value: ephemeral
- key: REDIS_URI
  value: redis://redis

Whenever you modify and save an environment's configuration, the environment's configuration version number is incremented. The version number is made up of the version of the Application Template the environment was based on (the first digit), and the version of the environment-specific configuration currently deployed (the second digit). Changes to an environment's configuration will not change the first digit of an environment's version number. Saving an environment configuration file or environment variables file will change the second digit, incrementing the number by one.

In this diagram, you can see how different environments can be based on different Application Template versions:

GitOps workflow

When using GitOps, environment-specific configuration is automatically generated via a webhook processor that follows the workflow illustrated below.

With every push to your repository, Release runs this workflow to decide whether it should create new templates or configurations and whether it should deploy to any environments.

Pseudocode for the GitOps flow chart

  ##check if the Release GitOps files are modified
  if release_files_modified
    
    #get the template from the repo
    template_from_repo = app.template_from_repo

    #loop through every app for this repo that matches the branch
    repository.apps.with_branch(branch).each do |app|

      ##diff the template, if true, generate and save new templates
      if diff(template_from_repo, app.previous_template)
        generate_new_templates(app).save
      end
    end

    #for every active environment for the repo that matches the branch
    repository.active_environments.with_branch(branch).each do |env|
      
      #transform app template to environment configuration
      env_config = transform_app_template_to_env_config(env)
      
      env_config.save
  
      #if you want to deploy any matching envs, this setting must be true
      if should_deploy_active_envs_that_track_branch_with_config_change?
        deploy_env(env)
      end
    end
  end

GitOps allows you to have different environment configurations in different branches that can be merged back to your main branch. In the same way you work on features and bugs in branches, you can try new configurations by making changes to your Application Template and environment variables in branches. When you merge back to your main branch, your configuration changes will be included. GitOps automatically pushes and deploys configuration changes to your Release environments.

Figure 1. Both configuration files in the .release directory