Getting started
Guides and examples
Reference documentation
Background concepts
Frequently Asked Questions
Integrations
Preparing Your Account
Account Creation
One of the first steps in getting started with using Release is creating an account. Release supports the use of one of the following source control systems: GitHub, GitBucket, GitLab. Release will integrate with your source control system and create your account.
You may want to log in to Release and turn off automatic PR creation until you are ready to use Release. This will prevent failed builds and deploys from cluttering your view and worrying developers working on the codebase.
Cloud Integration
Release will need to integrate with your cloud provider to provision and manage your new environment. Release currently supports Amazon Web Services, Amazon Web Services Gov, Google Cloud Platform for cloud integration.
Refer to the appropriate guide for connecting your cloud provider to release:
Creating Cluster
When it comes to creating a cluster, we need to think about sizing it appropriately. This will heavily depend on your application stack, use case, and team size. There is no right or wrong way to start your cluster, however, you will want to plan ahead to avoid creating issues down the road. In general, there are three major decisions you will need to make. Just keep in mind that nothing is set in stone and Release makes it relatively easy to make changes and update things as time goes on or as circumstances change.
DNS Names
Release will build your ephemeral environments under a subdomain that you control. You will want to choose a domain that is short (so it’s easier to type) and clearly identifies that your environments are ephemeral. Keep in mind that this discussion does not include production or staging environment names, that is a separate discussion we can have later. It is also not advisable (but not prohibited) that you run ephemeral and production environments together. Other types of permanent (but not production) environments include QA, performance testing, and UAT environments which fit into this category.
Most customer simply use the “release” subdomain along with their corporate domain name, for example:
1
release.example.com
Copied!
So that your environments might be named:
1
serviceA-envA.release.example.com
2
serviceB-envA.release.example.com
3
serviceA-envB.release.example.com
4
serviceB-envB.release.example.com
Copied!
…and so on. Other customer use a development domain that is separate from their corporate domain name, for example:
1
release.example.dev
2
release.example-dev.io
Copied!
The choice is yours!
Node Type
Release uses Kubernetes clusters under the hood, which means that you will set a minimum and maximum number of nodes as well as the type of node that your cloud provider will use to host the workloads. There is no way to know in advance what size of cluster you will need. The best option is to choose the defaults (min: 3, max: 10, type: 16GiB/4 CPUs) unless you know for sure how many environments you will be running at once and what each workload will be.
The good news is that Release makes it very simple to upgrade, increase, decrease, or resize your cluster later seamlessly without any interruption.
Network Addresses (CIDR Blocks)
This section is the most advanced and technical. Release environments run inside your own cloud provider account and they might need to be connected to existing services and applications that you run in your account. Please note that there is no need to connect the environments; in fact, you can keep the Release environments completely separate from your other running applications as you see fit. The point here is that you might want to connect existing applications or services to your Release environments.
In order for Release environments to work and not interfere with any existing applications, we select a network address or CIDR block that is distinct from the other network addresses you use in your enterprise. If you know which CIDR block to use, go ahead and tell us what it is when we create the cluster and we will build a Virtual Private Cloud with the unique CIDR block you provide. If you do not know what block to use, or you have no idea and can’t figure it out, you can use the defaults.
See Also
Last modified 23d ago