Can anyone explain why they might go with a slack based deployment system as opposed to something more robust like CircleCI or Jenkins? Is it mainly about the simplicity of it?
Here's a relevant talk from 2013: https://youtu.be/NST3u-GjjFw
To be clear, it's hopefully just some connector that does slack message -> triggers jenkins job.
But from a security, compliance, reliability, debuggability, auditability perspective I think it's inferior. Not to mention an inferior interface.
We liked it because the chat history you see is essentially a deploy history, no need to login into some other website to check some obscure logs page to see who did what. We did end up having to debug the service that processed the chat messages maybe once, but never ran into an issue when we had to deploy a hotfix.
What I do is have all jenkins deploys send a record to the #deploys channel (Service X, version Q deployed by person Y completed successfully in Z minutes), which comes for free with a tiny jenkins plugin.
However one of the unicorns I worked at deleted all slack messages after 3 months for legal reasons, as one example. Also, slack has periodic outages.
I think a lot of people underutilize jenkins, but once you're handy with it (and get over its god-awful ui) you never go back.
Whenever I read comments like this I’m always deeply suspicious of the commenter (is that how you justify trying/adopting tech) or their employer (are they so draconian in tech/design choices that everything is frozen for good). I’m not trying to cast aspersions on you or your employer directly... but it’s fascinating to me to see such a myopic take on a problem space I hope you’d agree is very much not one-approach-fits-all. I’m surprised to hear about their flow too, but my more charitable assumption is that their teams have tried different things and settled on an evolving process that works for them. They’re proud enough to boast it from the corporate blog, it can’t be entirely lark.
Our UAT environment is deployed with fixed versions, and is only updated either after a sprint, or when the business wants to test new features. Generally this is done by someone from the business asking to deploy a new version, and then a developer manually triggering this process. I see no reason as to why the business wouldn't just be able to do this through Slack, and not have developer act as a middleman.
However, if your UAT is a manual refresh with no branch names, for example, that seems perfectly reasonable (so long as it's triggering a pipeline like you mentioned).
However if I worked where you worked and you wanted slack to deploy prod, I'd probably try to talk you out of it.
My annoyance at the moment is that business side will often ask "have we deployed the latest code to UAT?", to which I quickly open Jenkins, check when the latest job ran, and revert back to them. I have tried just linking the Jenkins URL back to them, as to say, "look it up yourself". But I suspect business people just don't want to touch Jenkins, because it's a "technical tool". So my idea has always to been build a simple chat bot, where they can ask when the latest deployment was, and where they'll be able to trigger a new UAT deployment.
> However if I worked where you worked and you wanted slack to deploy prod, I'd probably try to talk you out of it.
We have pretty strict deployment processes for prod, where other teams do the deployments, and it's not even allowed to automate that.
Maybe those who can post to your deployment slack channel, can deploy? So you configure who-may-deploy via permissions in Slack instead?