Automated Deployment to APPUiO Cloud

tobru commented 2 years ago

Summary

As product owner I want to have automated deployment to APPUiO Cloud So that I can have fast feedback on the development.

Context

Enhance the GitHub Actions to deploy to APPUiO Cloud:

Preview deployments for PRs
Deployment to production on tagging

Out of Scope

Production deployment. This is done with Project Syn (GitOps, ArgoCD)

Further links

No response

Acceptance Criteria

When pushing a commit to master, then new image is built and new deployment rolled out in integration
Given an existing branch, when PR is created, then build a new image, deploy a preview instance with generated URL and post a notification in the comments
Given an existing PR, when PR is closed, then purge the PR-specific preview instance and delete the image.

Implementation Ideas

No response

ccremer commented 2 years ago

Deployment to production on tagging

I've made the experience that only doing deployments on git tags may not cover all cases. For example, there could be a simple DNS change or just upscale in replica, for which a new tag would have to be made.

I propose to run deployments on any commit in master. If there wasn't a change that impacts the deployment, then nothing happens anyway. WDYT?

tobru commented 2 years ago

Yes, that's a good approach :+1:

ccremer commented 2 years ago

Revisiting this topic again. Do we really want to deploy to production via pipeline in this repository? Every other APPUiO cloud component is managed via Project Syn. I could imagine that we may want to prefer to maintain production instance with GitOps / Commodore component, while having a Review-App-workflow with pipelines for preview deployments.

If this sounds reasonable, I would propose the following implementation:

Create a helm chart in appuio/charts repository. (In fact, I started already on it, couldn't help myself: https://github.com/appuio/charts/pull/380)
Create a Helmfile deployment in this repository that deploys the Chart for previews
Commodore component (maybe https://github.com/appuio/component-control-api/?) reuses also the Helm chart for generating deployment manifests.

I think using the stack described above provide a good-enough compromise of GitOps and Review-Apps.

tobru commented 2 years ago

I'm OK with the proposed process, it's good enough for now.

Although I'm not a big fan of it, I prefer to have everything of an application at the same place: application code, deployment artifacts, pipelines. With the proposed workflow everything is scattered around: code is here, helm chart is in separate chart repo, deployment is in commodore component and the actual deployment is in the tenant repo: 4 places to look for things.

ccremer commented 2 years ago

You raise good points and I understand them very well. I just thought deploying production here would be inconsistent to how we manage Zones with Syn usually, there would be the exception of the portal.

The other way could confusing as well: engineers asking themselves where the deployment is coming from, how to scale up or change an image tag, configure oauth... Instead of adjusting values in the usual Commodore places, they'd have to come to this repository just for the portal. Besides, there may be a point soon where we need to configure secrets, and having to encrypt them here with SOPS or use GitHub secrets is a much bigger operational "break" or antipattern than what Syn/Vault provides.

Let's have a team discussion to decide. Moving the chart to this repository is easy should we decide for full review-app workflow.

ccremer commented 2 years ago

We discussed it in the team today and came to the following conclusion:

Frontend previews are set up and teared down using Pull Requests as initially proposed
Production deployment is managed via Commodore / Syn using Git tagged releases as that's the preferred method for the engineers operating the cluster.
There will be a long-running integration environment that is deployed via GH actions by pushing to master. That way we have a stable pre-production environment to test things out in-depth before releasing it.

A question came up how we decide to deploy the backend part of the control-api. Is the frontend being paired with a Preview deployment of the backend? Or do we develop backend features first and frontend always uses the integration environment of the backend...? We don't have answers yet, but they will be needed later.

appuio / cloud-portal