Tag based Deployments

[Schnitzel]

Find a way that we can also deploy based on Tags.

[renebakx]

that would be awesome, and actually is one of my major showstoppers for moving to a Lagoon based flow. We as a team of 4 mostly commit to master and actually only want to build a new artifact if there is activity in either the production or staging branch and not on every commit to a repository.

Having tags or hooks that only go off on a push to those branches would be nice. For now my solution would be to add a 'proxy' to the webhooks and filter out the ones we don't need. But in the long term it would be awesome if that was configurable in lagoon or perhaps in the lagoon.yml file.

[thom8]

@renebakx as a work around we have a specific production branch that we sync with the latest release tag when we're ready for a new production deployment, this way we can also control when the deployment happens rather than having to rely on when the tag was created.

The production branch is also protected to only allow release managers to push directly to the branch.

We also have the ability to rollback to a previous tag by reseting and force pushing to the production branch and restoring the database if it's required.

[renebakx]

Thank you :) That is one of the things Kelsey Hightower was talking about on a kubecon video I just watched. It felt kinda overkill for a small team, but perhaps it isn't in practice.

Just need to figure out a way on how to keep that manageable without me being the single point of failure as end boss of what goes into production or not :)

[Schnitzel]

@renebakx
another solution we currently implemented: Promotion Deployments.
Basically it allows you to tell Lagoon to take all Docker Images of a Branch Based Environment and use them in another Environment. this Promotion can only be triggered by a REST call and is not connected to any Git based actions, the workflow works like this:

Assuming you have a staging branch and a master branch.

1. Push into staging branch, deploys the staging environment
2. Test the staging environment
3. Merge staging into master it automatically deploys the master environment
4. Do a Hotfix to master environment because you found an issue, it deploys again the master environment, test again, now you are happy
5. Now trigger a promotion from the master environment to the production environment. Lagoon will do the following:
   1. Create the production environment
   2. Move all the Docker Images from master to production
   3. runs all post-rollout tasks on production

So this gives you the possibility to trigger a deployment completely decoupled from Git Branches, and also you are guaranteed the the promoted environment is 100% the same as the source environment as it uses the same Docker Images :)

Would that be an alternative?

[rtprio]

I briefly compared how other providers are doing this.

The design I am thinking of so far is a column 'tag' would be added
to the environment table. There are then two ways this could be used.

first

One way is that the production tag is set in the UI.
A user would use the UI to update the tag for the desired environment.
Then that tag would be triggered as part of that process.

second

The second way I thought of is to use a regular expression
or pattern similar to branch pattern. I haven't worked out all the
details with this one.

e.g. The tag for production environment would be set to production-.*.
When a tag is pushed, and it matches the regex, it is delpoyed to that
environment. An unanswered question is what if the matching tag is on
a different branch.

[mxr576]

up :)

Edit: Maybe Acquia's solution can be used for inspiration: https://support.acquia.com/hc/en-us/articles/360047440074-Creating-releases-and-deploying-code-on-Acquia-Cloud

[nicksantamaria]

Any thoughts on where this fits on the roadmap?

[nicksantamaria]

@Schnitzel I notice this ticket is flagged as being in the Lagoon 2.0 milestone, however there are no issues or pull requests on the Lagoon 2.0 project board.

Do you think its realistic for this to be in scope for lagoon 2?

[tobybellwood]

(my bad, it's still marked as Lagoon 2, even though we're well into Lagoon 2 now) - @nicksantamaria this is still something under consideration, but not actively under development - but we'd need to set aside time to very carefully plan it out, and work out what the risks and opportunities are.

[AubreyHewes]

Tag based deployments is something our organisation is very interested in. I cant believe it is not interesting for any release based org..
Is there any timeline for this?

[p1n5u]

We are also interested in tag-based deployments primarily due to our existing process:

Our current workflow involves triggering a pipeline upon tag creation in Git. This pipeline is designed to validate the code, deploy a pre-release environment, run end-to-end tests, create a Git release, and then initiate a deployment. However, we face challenges with the default behavior of deploying the latest changes from the main branch. This can potentially result in deploying "untested" code if changes are pushed to the main branch during pipeline execution.

To manage this, our current approach involves canceling the pipeline if new commits are detected since its initiation. However, this can lead to wasted time and resources, as the entire pipeline may run without achieving a deployment (including code validation, e2e tests, etc.).

It would be highly beneficial for us to enhance our deployment process by implementing a method to trigger deployments to the main branch using specific tags. This enhancement would ensure that only tested and validated code reaches production, addressing our current challenges effectively.

[eiriksm]

+1 we use tags for production releases exclusively

[truls1502]

+1