CI = Continuous Integration
Modern CI is too complex and misdirected (2021)
31–40 of 207 posts
Re: Modern CI is too complex and misdirected (2021)
#32I've been able to effectively skip the entire CI/CD conversation by preferring modern .NET and SQLite.
I recently spent a day trying to get a GH Actions build going but got frustrated and just wrote my own console app to do it. Polling git, tracking a commit hash and running dotnet build is not rocket science. Putting this agent on the actual deployment target skips about 3 boss fights.
Re: Modern CI is too complex and misdirected (2021)
#33I remember a Rich Hickey talk where he described Datomic, his database. He said "the problem with a database is that it's over there ." By modeling data with immutable "facts" (a la Prolog), much of the database logic can be moved closer to the application. In his case, with Clojure's data structures. Maybe the the problem with CI is that it's over there . As soon as it stops being something that I could set up and r…
> Part of the problem, maybe the whole problem, is that we could get it all working and portable and optimized for non-blessed environments, but it still will only be expected to work over there, and so the frog keeps boiling.
Build the software inside of containers (or VMs, I guess): a fresh environment for every build, any caches or previous build artefacts explicitly mounted.
Then, have something like this, so those builds can also be done locally: https://docs.drone.io/quickstart/cli/
Then you can stack as many turtles as you need - such as having build scripts that get executed as a part of your container build, having Maven or whatever else you need inside of there.
It can be surprisingly sane: your CI server doing the equivalent of "docker build -t my_image ..." and then doing something with it, whereas during build time there's just a build.sh script inside.
Re: Modern CI is too complex and misdirected (2021)
#34IMO development is too complex and misdirected in general since we cargo cult FAANG.
Need AWS, Azure or GCP deployment? Ever thought about putting it on bare metal yourself? If not, why not? Because it's not best practice? Nonsense. The answer with these things is: it depends, and if your app has not that many users, you can get away with it, especially if it's a B2B or internal app.
It's also too US centric. The idea of scalability applies less to most other countries.
Re: Modern CI is too complex and misdirected (2021)
#35'Continuous Integration' in case anyone is wondering. Not spelled out anywhere in the article.
Re: Modern CI is too complex and misdirected (2021)
#36Any universal build system is complex. You can either make the system simple and delegate the complexity to the user, like the early tools, e.g. buildbot. Or you can hide the complexity to the best of your ability, like GitHub actions. Or you expose all the complexity, like jenkins. I'm personally happy for the complexity being hidden and can deal with a few leaky abstractions if I need something non standard.
Re: Modern CI is too complex and misdirected (2021)
#37I remember a Rich Hickey talk where he described Datomic, his database. He said "the problem with a database is that it's over there ." By modeling data with immutable "facts" (a la Prolog), much of the database logic can be moved closer to the application. In his case, with Clojure's data structures. Maybe the the problem with CI is that it's over there . As soon as it stops being something that I could set up and r…
I want my build system to be totally declarative Oh the DSL doesn't support what I need it to do. Can I just have some templating or a little bit of places to put in custom scripts? Congratulations! You now have a turing complete system. And yes, per the article that means you can cryptocurrency mine. Ansible terraform Maven Gradle. Unfortunate fact is that these IT domains (builds and CI) are at a junction of two fa…
Alternative take: CI is the successful monetization of Make-as-a-Service.
Re: Modern CI is too complex and misdirected (2021)
#38IMO development is too complex and misdirected in general since we cargo cult FAANG. Need AWS, Azure or GCP deployment? Ever thought about putting it on bare metal yourself? If not, why not? Because it's not best practice? Nonsense. The answer with these things is: it depends, and if your app has not that many users, you can get away with it, especially if it's a B2B or internal app. It's also too US centric. The ide…
Requirements are complex too. Even if you don't need to scale at all, you likely do need zero-downtime deployment, easy rollbacks, server fault tolerance, service isolation... If you put your apps into containers and throw them onto Kubernetes, you get a lot of that "for free" and in a well-known and well-tested way. Hand-rolling even one of those things, let alone all of them together, would take far too much effort.
Re: Modern CI is too complex and misdirected (2021)
#39IMO development is too complex and misdirected in general since we cargo cult FAANG. Need AWS, Azure or GCP deployment? Ever thought about putting it on bare metal yourself? If not, why not? Because it's not best practice? Nonsense. The answer with these things is: it depends, and if your app has not that many users, you can get away with it, especially if it's a B2B or internal app. It's also too US centric. The ide…
many ppl also underestimate how capable modern hardware is: for ~10usd you could handle like a million concurrent connections with a redis cluster on a handful of VPSs...
Re: Modern CI is too complex and misdirected (2021)
#40The issue that I see is that "Continuous integration" is the practice of frequently merging to main.
Continuous: do it often, daily or more often
Integration: merging changes to main
He's talking about build tools, which are a _support system_ for actual CI, but are not a substitute for it. These systems allow you to Continuously integrate, quickly and safely. But they aren't the thing itself. Using them without frequent merges to main is common, but isn't CI. It's branch maintenance.
Yes, semantic drift is a thing, but you won't get the actual benefits of the actual practice if you do something else.
If you want to talk "misdirected CI", start there.