Gitlab Path to Production using Protected git tags

Environments should be protected too, so that you can use the deployments feature to roll back. Protected environment approvals is also handy for scheduling roll outs in deployment windows.

Do check:
1. Your higher environments are protected
2. Your tags are protected. I strongly suggest three letter $STG-$DATE rules
3. Ensure your deployment runners are also protected to try prevent accidentally usage

[sergeypolanco]

OMG BRO Thanks a lot you solve me all my questions about how to trigger the tags

[pharmajoe]

I’ve used a similar approach with the only difference being merge requests are deployed to staging repeatedly. When we want to release we then create a tag. Serves us well

[getrekt]

Do I am the only one who see an animation on the like button while watching the video, at 9 minutes and 10 secondes, while he says "like the video" ?

[MnemonicCarrier]

Thanks - very interesting 😄I'm trying to set up a GitLab runner at the moment (so I don't have to use the slow shared runner).

[sergioteixeira]

when deploying to staging/prod in my opinion you should promote the ci/cd artifact/container, so you are sure what you tested in dev is what gets promoted.

[puttenicole]

This trigger a new job every time you tag? Different artifacts?

[joelamoako]

make more real life devops videos. thanks for this though