[dielectrikboog]

Sounds like you’re going to be depressed when you learn how the entire Internet plane, all software engineering outside of “SV”, all IT, all government, and basically everything except your GitHub CI/CD adventure works, then. Sorry.

[jmb12686]

This isn't an accurate statement. I work on behalf of a federal government agency, and no one has write access in development, let alone production. Everything is required to run thru our ci/cd pipeline. Times are changing.

[dielectrikboog]

For the better? I’m not asking out of preference, I’m asking out of actual conclusion: is trading the operational overhead of running LDAP for a usually homegrown, usually wobbly automated scripting soufflé that turns Make into a distributed system objectively better? Has nobody stopped to ask, is DevOps and CI/CD the best framework we can achieve? Did nobody think to ask before they told your agency it was the ‘right’ methodology and the objectively best way to build industrial, business process software in the government sector? Did the changing times come from ideology and belief or identified process gaps?

I ask because I think there’s something better. I don’t know what it is yet, but I want to find out. I’m worried about wastage in DevOps methodologies, a system where nobody is incentivized to care about the right things, going on to spook the policymakers on doing software before we find out if the DevOps and Cloud worlds, both, are objectively the best way to do software for their purposes. I strongly, strongly feel like the craft is on the wrong path, and persuasive successes in industry are getting to the right ears before we know if the discipline to efficiently handle agile infrastructure with today’s tooling is even possible. I’m not convinced DevOps will organically find the right calculus to spur the kind of systems research that took us to not only where we are, but that which will take us where we need to go.

Speaking of, I’m lazily glancing at Agile here as well but I’m not prepared for a coherent argument there, beyond pointing out that we now have better tooling for managing specifications, particularly formal and mathematical ones, than the waterfall development experiences that prompted agile thinking. We need more systems research, tinkering, rethinking POSIX, all of it.

[gonzo41]

Imagine a Graph, the x-axis is time or adoption of a set of technologies. Right now the hump in the bell curve is CI/CD and devops. It's safe to be in a large group. If something better comes along then it'll start happening and in 15 years I expect the whole of government to adopt it when you are bemoaning the pitfalls of any new approach.

[dielectrikboog]

I know what a hype curve is, and I made two substantive points to differentiate this situation from a hype curve. I’m not “bemoaning the pitfalls,” I’ll repeat that I’m concerned this approach, which is gaining traction and getting solidified and entrenched, will spook the decisionmakers on being willing to accept your 15-year solution when it comes along.

If you’re going to be as patronizing as you are, please at least read what I’ve written and respond to it.

[gonzo41]

CI/CD is a good enough framework at the moment. The goal is to build things and ship product to customers. It does that well and thats why it's winning.

The fact that a jenkinsfile starts with groovy and can include N number of different languages is just the nature of the beast. There is always fragmentation in software integration, and devops is integration on steroids.

Any other methods, formal or otherwise, need to provide X value at a cost of Y that makes adoption worth it. Currently if you don't use CI/CD then the value and cost propositions of adopting CI/CD actually start to make a lot of sense if you are mature enough to accurately do cost accounting on your IT management processes.

Yes, it's true, Jenkinsfiles, Cloudformation Json and Yaml all suck to work with. And configuration management is tricky. But I know that we'll all think the same thing about any other system or approach we adopt because it'll end up being work.

CI/CD may be a trade off but it allows us to focus on business problems rather than technical ones.

[zodiac]

I dont disagree with many of your points, but are you advocating "logging into a production system and editing the config file in nano"? Can't tell if you are...

[aprdm]

Even within SF. Having talked with a bunch of folks from Amazon and Netflix they're far from having most of their workflows running in containers... imagine is the same for google.