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?
As a devops person myself, I am super skeptical that there is any good reason to do a chatops deploy. My guess is "new toys are cool" / "Want this on my resume"
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.
> My guess is "new toys are cool" / "Want this on my resume"
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.
chatops deploys aren't really new toys, a place I was at was doing them around 2013/14.
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.
I really don't see how the chatops approach highlighted in the blog post changes anything. It seems that they're typing a command in Slack, and this triggers a pipeline. Which is something I've been wanting to introduce for our team.
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.
Yeah where I work product people tend to deploy UAT or QA environments. They do it in jenkins, because a stack consists of multiple services, and they may want to choose which branch to deploy. It would be cumbersome to type a combination of branch names in chat.
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.
Good to get some insights in this; in our case, we always deploy our develop branch to UAT. Because our releasable code is all the business cares about. We have another SIT environment that we sometimes use for feature branches.
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.
What I would debate doing in your use-case is have every merge to "develop" branch automatically trigger a deploy to UAT (another option is to set an autobuild every night). There's a jenkins plugin for that.
My team recently put in automation so that we use CircleCI for the staging deployment, have it wait for manual approval, then deploy to production. However, we can also give the Slack staging deployment message a +1 reaction, which will automatically approve the production deployment for CircleCI. This way, we get an easy dev UX but all the CI features of CircleCI.
It's mainly the simplicity of the deployment system as it's inline and visible, coupled with habit. It all actuality that is just what _can_ trigger the deploy, the actual deploy is based on an internal deploy application and deploys can be triggered from there as well.
There's easy transparency amongst multiple teams, without having accounts for the other teams on CircleCI or Jenkins. This is while the deploy is in flight, and it can provide timestamped logs if there's an incident, and it could be useful for tracking history. It's also clear who kicked off the deploy.
