12 Things You Didn’t Know You Could Do With Release (Part 2)

‍This is part 2 of a 2 part series on things you didn't know about using Release. Read Part 1 to get started.

You may know that Release makes environments easy by allowing anyone to create full stack, isolated environments for development, testing, quality assurance, user acceptance testing, or even production. But did you know that there are a lot of other things you could use Release for that you may not have thought about? This guide will help you find some really cool hidden tips and tricks for maximising your enjoyment and delight using Release!

#7: Enable Your Sales Teams and Customers to Quickly Demo or Proof-of-Concept Test Your Product

With Release, it’s fantastically easy to spin up environments for any purpose. You can share your latest user acceptance tests with customers or your product team. But environments can be used by almost anyone in your company: for example, you can let your sales team spin up the latest preview version of your product and demonstrate it to a customer live: not a mock up or demonstration in a shared account, but a fully-fledged production-capable environment. This environment could be ahead of or behind the full production release cycle. The demonstration environment could even be customised for each customer and given full access to the potential or existing customer to “play with” a live demonstration for a limited period of time. Once the demonstration or proof of concept period is over, the environment can be turned down, deleted, or recycled without any intervention from DevOps or other technical teams.

#8: Host a Hackathon

One of my favourite things to participate in at work that I wouldn’t even consider work is joining a Hackathon and banging out a demonstration or proof of concept of a minimal viable product idea. Joining with my team to deliver an idea starting from nothing to tangible demonstration, spending all night, or several days and nights in a row if needed, is an amazing thing to do and I recommend this experience to every engineer, regardless of field or industry.

In terms of software development however, the truly special fruit of this endeavour is being able to see the results of your efforts running live within minutes of each change. Simply have all your teams start with a “hello world” template (even better, start off with your whole product stack as the initial “hello world” demonstration!) and turn them loose in their own pull requests and branches to write amazing code and unleash their ideas instantly.

The judges can easily see the results of the code by scanning the environments and testing the code live. May the best team win! :heart_emoji: :starry_eyes_emoji:

#9: Stay Secure and Up-to-Date With Latest Code Dependencies

At Release, we are very keen to keep our code secure and constantly up to date with all the latest updates and dependencies. Every time a Dependabot or Renovate issue is opened, we know all too well the sinking feeling of having to test and verify every update. Simply merging in all the changes can potentially break your application in the most insidiously small or sometimes the biggest, most horrendous ways possible. Testing every single change is a daunting task to say the least. The easiest path is to avoid these notifications and keep ploughing ahead. But you create a real risk in ignoring updates and patches that might make your code vulnerable to attacks or exposure of important data.

With Release, you can create a full-stack high-fidelity environment for every pull request or via labels when Dependabot or Renovate scans your repository for updates. Testing each application stack is straightforward because the links to the environment are ready and available in the comments or the Release UI. You can also run automated tests as well or in lieu of manual testing to verify functionality of your application. You can then simply approve and merge the PR to immediately promote the latest (hopefully up-to-date and secure) version out to production with a minimal amount of toil and labour for each proposed change.

#10: Control Public or Private Access to Your Services

Did you know that you can hide your services behind a VPN or internal tunnelling tool to your cloud provider? For AWS customers, we support Transit Gateway out of the box to handle routing, but you can also use VPC peering or Client VPN to connect to internal services. GCP customers can also use Cloud VPN to reach internal and private services securely and safely. You can even mix public services (like a frontend and backend API) and private services (like an internal administrative interface) in one environment. You merely need to specify the <code inline>visibility</code> parameter for each service as shown in our docs and below:

rules:
  - service: admin
    hostnames:
      - admin-${env_id}.internal.example.com
    path: "/"
    visibility: private
  - service: backend
    hostnames:
      - backend-${env_id}.${domain}
    path: "/auth/"
    visibility: public-direct
  - service: frontend
    hostnames:
      - frontend-${env_id}.${domain}
    path: "/"
    visibility: public

#11: Run Your Own Application Infrastructure and Supporting Services

You may need supporting “infrastructure” in your application stack that are actually shared services, like ElasticSearch, Kafka, RabbitMQ, Prometheus, PostHog, Solr, and on and on the list goes. You can easily create an application based on any open-source Helm chart (or your own, obviously) and deploy shared permanent environments (like QA, staging, etc.) or ephemeral environments only used for a short period of time for testing and integration. You can also use the Release App Imports feature to include an application into your environment stack with one additional line of configuration.

Similarly, almost any open-source application that has a <code inline>docker-compose</code> file (or one that you make) can be imported in literally minutes to create a full application stack that can be either used as a stand-alone shared environment or imported into your own application stack environment. In this way, virtually any application repository in GitHub, GitLab, or Bitbucket can become part of your own internal hosted application stack in minutes rather than hours or days of trying to build and install software in your application stacks. Plus, you can create as many environments as you like, both permanent and ephemeral.

We have several customers who were able to build these supporting infrastructure applications live in their own accounts faster than they could deploy their own code due to how easy off-the-shelf open-source applications can be installed via Release.

#12: Reference Secrets in Your Services, Jobs, and Build Arguments

Everyone loves secrets and if you believe the band U2, a secret is something you tell someone else. Well, not on our watch at Release! We currently have support for several secrets sources: own own internal encrypted store (where all our built-in secrets and environment variables are stored) which is published to your Kubernetes cluster as a secret and encrypted there too, AWS Parameter Store (SSM), and AWS Secrets Manager (support for GCP Secrets Manager is coming soon, let us know if you are interested).

If you have an API token or an application ID you need to keep covered up but not necessarily secret, you can use our built-in secret store and reference it in either build arguments or environment variables like this:

service:
  backend:
      - key: API_TOKEN
        value: 123456
        secret: true

Once you save the value it will be swallowed up in our vault and never see the light of day again until your application accesses it at runtime.

Another option is to pull from either SSM or Secrets Manager (AWS, today) by reference:

service:
  backend:
      - key: API_TOKEN
        value: $secrets.ssm./path/to/some_token
      - key: DATABASE_PASSWORD
        value: $secrets.secretsmanager./prod/db/main_password

In this way, Release gives you access to your own secrets in your own account so a secret is truly something you never have to tell someone else. You can read our top-secret documentation about secrets here.

Conclusion

This completes our series on 12 things you may not have known about using Release, see Part 1 here. We hope you have enjoyed these tips and they inspire you to try a few on your own, or contact us to get a demonstration of how these tips work. If you have any ideas or ways that you have implemented something similar, drop us a line at hello@release.com, we’d love to hear from you!