The more and more I use CICD tools, the more I see value in scripting out my deployment with shell scripts and Dockerfiles that can be run anywhere, to include within a CICD tool.

This way, the CICD tool is merely a launch point for the aforementioned deployment scripts, and its only other responsibility is injecting deployment tokens and credentials into the scripts as necessary.

Anyone else in the same boat as me?

I’d be curious to hear about projects where my approach would not work, if anyone is willing to share!

Edit: In no way does my approach to deployment reduce my appreciation for the efforts required to make a CICD pipeline happen. I’m just saying that in my experience, I don’t find most CICD platforms’ features to be necessary.

[–] synae@lemmy.sdf.org 11 points 1 year ago

You're not advocating against CI like the meme seems to be, but rather for CI builds to be runnable on human's machines and the results should be same/similar as in when running w/in the CI system. Which is what CI folks want anyway.

[–] xilliah 5 points 1 year ago (1 children)

What about related tools such as viewing artifacts such as for example total memory usage, and graphing that in the browser.

And sending emails, messages etc in case of a failure or change.

[–] CodeBlooded@programming.dev 3 points 1 year ago (1 children)

Most of those things mentioned aren’t bona fide needs for me. Once a developer is deploying their project, they’re watching it go through the pipeline so they can quickly respond to issues and validate that everything in production looks good before they switch contexts to something else.

I see what you’re saying though, depending on what exactly is being deployed, the policies of your organization, and maybe expectations that developers are working in another context once they kick off a deployment, it could be necessary to have alerting like that. In that case it may be wise to flex some features of your CICD platform (or build a more robust script for deployment that can handle error alerting, which may or may not be worth it).

[–] xilliah 1 points 1 year ago

I come from game dev. We do lots of checks on the data that all kinds of people can screw up. So it's important these situations are handled automatically with an email to the responsible person. A simple change can break the game, or someone might commit an uncompressed texture so the memory usage jumps up.

[–] gandalf_der_12te@feddit.de 2 points 1 year ago

Honestly, CI is only meaningful on bigger projects (more than 100 man-hours invested in total). So I most often go without.

But I do see its point.

[–] killabeezio@lemm.ee 2 points 1 year ago

Then you would probably enjoy concourse

[–] Lanthanae@lemmy.blahaj.zone 21 points 1 year ago (1 children)

Counterpoint: watching little green checkmarks appear when my PR passes a pipeline step gives me dopamine

[–] Faresh@lemmy.ml 2 points 1 year ago (1 children)

I'm a bit confused. I thought "build system" referred to systems like autotools, scons or cmake. How are they related to green checkmarks? Couldn't one also get green checkmarks when using a build shell script or makefile?

[–] Lanthanae@lemmy.blahaj.zone 2 points 1 year ago

Is a CI/CD pipeline not a build system?

(this isn't a "gotcha", I genuinely may have misunderstood the post)

[–] argv_minus_one 16 points 1 year ago (1 children)

If you want to take Cargo away from me, you'll have to pry it from my cold, dead claws. 🦀

[–] sip@programming.dev 4 points 1 year ago (1 children)

I don't think cargo is the problem. it's idiomatic and it's like "build.sh"

[–] argv_minus_one 8 points 1 year ago (1 children)

Cargo fetches dependencies, runs a variety of build tasks, can build a typical Rust project with little or no build scripting, and is configured with a straightforward TOML file. It's not at all like a hand-written shell script. It's also much more pleasant to use than any other build system I've seen, including shell scripts.

[–] sip@programming.dev 2 points 1 year ago (1 children)

yea, as I said, it's idiomatic. it replaces the need for a build.sh.

[–] argv_minus_one 2 points 1 year ago

Is that not true of all build systems?

[–] synae@lemmy.sdf.org 16 points 1 year ago

Allow me to blow your mind: my Jenkins build calls build.sh because I'm not a fuckin idiot

[–] morrowind@lemmy.ml 12 points 1 year ago

WHAT THE FUCK IS BUILD.SH, ALL MY CODE IS IN MAIN.C JUST COMPILE THE DAMN THING

[–] r00ty@kbin.life 11 points 1 year ago* (last edited 1 year ago)

Joke's on you. I have a Jenkins hook from github to trigger build.bat! :P

[–] Sigmatics@lemmy.ca 5 points 1 year ago (1 children)

Yeah sure. Try building anything more complex than helloworld.c with a build.sh

[–] jcg@halubilo.social 11 points 1 year ago (1 children)

More complex build systems are just build.sh calling other build.sh in different configurations and using different software. It's build.sh all the way down.

[–] Sigmatics@lemmy.ca 2 points 1 year ago* (last edited 1 year ago)

The point is that "build.sh" implies a single file, which becomes an absolute nightmare to maintain on larger projects

[–] cupcakezealot@lemmy.blahaj.zone 4 points 1 year ago* (last edited 1 year ago)

I believe he goes by Leroy

[–] katre@programming.dev 4 points 1 year ago* (last edited 1 year ago) (3 children)

Ha ha. I work on Bazel (a great build tools, https://bazel.build), and I agree 100%.

[–] dingleberry@discuss.tchncs.de 3 points 1 year ago (1 children)

God I hate bazel/blaze.

[–] katre@programming.dev 2 points 1 year ago (1 children)

Thanks? I'm not sure why you wanted to share that with me.

[–] lukini 4 points 1 year ago

You shared randomly, they shared randomly. Balance in all things.

[–] socsa@lemmy.ml 3 points 1 year ago

Hey buddy can you step over here, there's a very tall cliff I want you to see

[–] AzzyDev 1 points 1 year ago* (last edited 1 year ago)

Please ignore everyone else being unkind - I’m somewhat new to build systems in general, what are the advantages/disadvantages of Bazel compared to other build systems?

[–] YurkshireLad@lemmy.ca 2 points 1 year ago

If I break our master build in CI, I get multiple emails and people saying "fix this"!!! I wouldn't have to fix it if you stopped letting people commit directly to master and stopped using git rebase! 😁

[–] MattTheProgrammer@kbin.social 1 points 1 year ago

I've been using Gearset for Salesforce CI/CD for a while and it's pretty simple to get up and running and it just kind of works. I'm looking into integrating it with Azure for our .net stack but not sure how smoothly that will go.

[–] MonkderZweite@feddit.ch 1 points 1 year ago* (last edited 1 year ago)

build.sh is no build system?

edit: URL arser should require *://.