[deleted]
Maybe we’ve not improved things as much as we think we have with Devops?
11–20 of 43 posts
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#12Y'know what? Up until Jan last year I had never even touched a server to deploy an app, much less set up a CI/CD/DevOps environment. Now, I'm comfortable with TeamCity, Octopus Deploy, Azure (a ton of hosted services), PowerShell, and a host of other tools. I've set up bunch of HipChat integrations so we know exactly where in our pipleline a particular build is (code pushed, dev build/deploy, and promotions to variou…
It's nice to hear of other people with a similar stack on HN (Azure, PowerShell, TeamCity, HipChat, and presumably C#/.NET)! It's working well for us too. In addition, we're increasingly doing more with ChatOps with mmbot (as an Azure Web Job): https://github.com/mmbot/mmbot One nice thing about mmbot is that if you use the DLL mode instead of the CSX mode, you get a great IDE debugging experience which makes it even…
Hah, we also use mmBot, but while it was our original plan to have it be our "DevOps 1 stop shop" we ended up shying away from that idea in favor of a more hands off approach. We still use our mmBot for a lot of back-office querying type operations, but decided that, at least for the moment, TC/Octopus will be our way forward.
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#13Y'know what? Up until Jan last year I had never even touched a server to deploy an app, much less set up a CI/CD/DevOps environment. Now, I'm comfortable with TeamCity, Octopus Deploy, Azure (a ton of hosted services), PowerShell, and a host of other tools. I've set up bunch of HipChat integrations so we know exactly where in our pipleline a particular build is (code pushed, dev build/deploy, and promotions to variou…
I don't know if you read the same article I did.
The author specifically said that we'd come a long way on tools but not made much headway on the people issues related to Dev/Ops.
Your comment does not appear to be adding anything to the article besides another anecdote that the tools are good (and if that is what you meant it to be, then I misread the tone of your comment).
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#14This recent trend of articles wrt to devops it making me want to post here.
Not trying to be too snarky, but why can't people just use shell scripts for automation?
They are easy to repair, in a language you (should) know, reproducible, and testable. They are native to your target, supremely portable, etc, etc.
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#15This recent trend of articles wrt to devops it making me want to post here. Not trying to be too snarky, but why can't people just use shell scripts for automation? They are easy to repair, in a language you (should) know, reproducible, and testable. They are native to your target, supremely portable, etc, etc.
Because it's not worth re-implementing the functionality available in Jenkins, Chef, etc. etc. etc.
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#16This recent trend of articles wrt to devops it making me want to post here. Not trying to be too snarky, but why can't people just use shell scripts for automation? They are easy to repair, in a language you (should) know, reproducible, and testable. They are native to your target, supremely portable, etc, etc.
Because it's not worth re-implementing the functionality available in Jenkins, Chef, etc. etc. etc.
This is a misunderstanding of the situation. Jenkins specifically has no business being anywhere near a production deployment; it is a development tool, despite "devops" people tending to use it as a web-interfaced crond.
Automation should be tooled to the production environment by people who are familiar with the production requirements and -- most importantly -- by the people who will be expected to maintain the environment and respond to critical issues.
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#17Y'know what? Up until Jan last year I had never even touched a server to deploy an app, much less set up a CI/CD/DevOps environment. Now, I'm comfortable with TeamCity, Octopus Deploy, Azure (a ton of hosted services), PowerShell, and a host of other tools. I've set up bunch of HipChat integrations so we know exactly where in our pipleline a particular build is (code pushed, dev build/deploy, and promotions to variou…
I don't know if you read the same article I did. The author specifically said that we'd come a long way on tools but not made much headway on the people issues related to Dev/Ops. Your comment does not appear to be adding anything to the article besides another anecdote that the tools are good (and if that is what you meant it to be, then I misread the tone of your comment).
My intention was more, "I went from 0 knowledge at the beginning of last year, to setting up a full devops pipeline on my own at the beginning of this year. What's your excuse?" But I wanted to highlight the tools I'm using as well.
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#18This recent trend of articles wrt to devops it making me want to post here. Not trying to be too snarky, but why can't people just use shell scripts for automation? They are easy to repair, in a language you (should) know, reproducible, and testable. They are native to your target, supremely portable, etc, etc.
Because it's not worth re-implementing the functionality available in Jenkins, Chef, etc. etc. etc.
Why do you think most people don't use cfengine?
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#19This recent trend of articles wrt to devops it making me want to post here. Not trying to be too snarky, but why can't people just use shell scripts for automation? They are easy to repair, in a language you (should) know, reproducible, and testable. They are native to your target, supremely portable, etc, etc.
How would you deploy a cluster with highly dynamic portions with shell scripts?
You end up with a process that pulls it from a database or something to fill out the configuration. At which point, you might as well just use a script in python or an existing system.
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#20This recent trend of articles wrt to devops it making me want to post here. Not trying to be too snarky, but why can't people just use shell scripts for automation? They are easy to repair, in a language you (should) know, reproducible, and testable. They are native to your target, supremely portable, etc, etc.
Bash scripts (to pick the most popular shell language) are hard to write, hard to debug (no stack traces), have weird historical artifacts, like not having named arguments to functions, or [[ $foo == true ]] or a whole slew of gotchas that make writing and maintaining them unpleasant.
If your application is written in ruby or python, why should you learn another (worse scripting, but that's just my opinion) language to deploy it?