Maybe we’ve not improved things as much as we think we have with Devops?
1–10 of 43 posts
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#2One problem is that existing devops tools are not that good.
For instance it seems insane to me that packer and vagrant exist as entirely separate products. As a java programmer I find that vagrant files are way too verbose. I am sure I could write some Ruby functions to take care of that and also to fix zillions of other things that are awful about Vagrant, but then everybody writes their own functions.
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#3Unfortunately, developing and deploying web applications is still a total nightmare. To build anything useful you'll need about four distinct package managers to get all of the necessary dependencies and some mish-mash of configuration management and provisioning tools to develop it, and perhaps a different set of configuration management and provisioning tools to deploy it. We can do better than this!
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#4Y'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 various environments), if there was a problem with a unit test run, if there were problems with integration tests, and if there are problems in dev/staging/production with our actual live running code via HipChat integrations with our structured log processing server.
There are good tools out there and they're pretty usable - just maybe not at your price-point of free for your environment. I went from 0 to 1-click whole-environment deployments in just over a year.
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#5Unfortunately, developing and deploying web applications is still a total nightmare. To build anything useful you'll need about four distinct package managers to get all of the necessary dependencies and some mish-mash of configuration management and provisioning tools to develop it, and perhaps a different set of configuration management and provisioning tools to deploy it. We can do better than this!
[deleted]
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#6One problem is that existing devops tools are not that good. For instance it seems insane to me that packer and vagrant exist as entirely separate products. As a java programmer I find that vagrant files are way too verbose. I am sure I could write some Ruby functions to take care of that and also to fix zillions of other things that are awful about Vagrant, but then everybody writes their own functions.
Try Docker instead. I can build Docker containers that provide our devs with a full blown dev environment that mimics production, which anyone on the team can then pull down with a simple "docker pull /:latest" command.
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#7Of course we haven't. In many cases, DevOps == have developers push code to production platforms.
IMO, there's been a lack of attention to the engineering side of the platforms themselves. In the places that I've seen that yammer on about devops, I see a lot of agile projects where version 1.0 works great, but the ongoing maintenance of the platform (whatever it is) is a complete nightmare.
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#8One problem is that existing devops tools are not that good. For instance it seems insane to me that packer and vagrant exist as entirely separate products. As a java programmer I find that vagrant files are way too verbose. I am sure I could write some Ruby functions to take care of that and also to fix zillions of other things that are awful about Vagrant, but then everybody writes their own functions.
Vagrant is a very well developed tool and has tons of configurations available in the Vagrantfile. It does take a lot of time to get deep into it however. When coupled with Chef's Test Kitchen, vagrant is a powerful tool. Side note; they actively review and accept pull requests.
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#9Y'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 faster to create meaningful ChatOps extensions. I've found it to be a more pleasant development experience that Hubot with CoffeeScript.
Re: Maybe we’ve not improved things as much as we think we have with Devops?
#10I think it's worth reflecting that not every improvement initiative (in this case: see DevOps) across the whole world is moving as one large entity.
The ending line: "Otherwise in my opinion it feels more like we’re treading water and not making the advancements we could be making." sounds like an existential fallacy to me - it has been my experience that although the "DevOps vision" has not changed significantly, the actual practices and evangelism of DevOps have been infiltrating and transforming the way organizations think about software engineering.