Re: CI/CD toolchains and lispworks

IMHO It depends on what your systems look like on deployment.   If its 
10's or more of end systems and there is no particular impact of 
updating then sure why not use CI/CD, most certainly it would save the 
aggravation of some other kind of scripting.   If its fewer systems, or 
if there are scheduling/ops related concerns then you're likely better 
off without.   Maybe if there are no scheduling/ops concerns at all then 
do whatever you prefer lol.

I'm on one project where everyone is hot for containers and such but the 
CI/CD and container system doesn't match well to how the software is 
used so the technology is often in the way and makes use and testing 
considerably more difficult.   Most of my software must run in a 
particular spot in the network, sometimes connected to the equipment its 
controlling, so containers and CI/CD only adds risk and complication.   
To complicate matters, updates have to be coordinated with the users.

OTOH the absolutely huge win is git and CM in general; we use branches 
extensively- its pretty much an essential technology for us to 
operate.     I keep my systems with deployment on master, or at least a 
designated release branch, and then use other tools to collectively 
update, and restart/resume as per what the update needs.

My model is to deploy with source and build in place, though deploying 
with binaries would be fine too.  The build-in-place isn't technically 
necessary but it has saved me on a few occasions when CM wasn't 
available because of IT/networking issues.   Since my use-case is a 
about a dozen systems, available via ssh, I can efficiently script 
deployments and software restarts at the appropriate times.   I 
definitely see how a different method would be needed if I couldn't get 
at fielded systems for some reason.   As much trouble as CI/CD has 
caused me operationally, it would be my last choice- I'd try using 
gitlab (or other) to distribute application rpm's or some other packages 
first.   There is enough complexity and fragility related to CI/CD that 
I would need to see a strong use-case before adopting it again.

Over the years I've had to design defensive measures into the software 
to protect it against IT;  the software fixes its own permissions and OS 
settings; on a number of occasions the hardening scripts that IT imposes 
have changed essential settings, access permissions and so on.   Its 
very frustrating to get support calls, only to discover IT folks have 
changed settings related to our software without testing, planning or 
even discussing the issue to find a compromise.   Sometimes I can head 
off that trouble because of the scheduled update; I can see right away 
if there is some kind of difficulty and mitigate right there and then.



On 7/6/2025 4:06 PM, Eben Bruyns (as eben at sdk dot co dot nz) wrote:
> Hi,
>
> Currently I have a makefile that uses some tooling I've built in 
> lispworks to allow me to automate my build and delivery. I'm about to 
> set up branches in my git repo to correlate to build channels I have 
> built into my delivered systems, I have a way within my software to 
> update itself from different delivery channels like stable, test, beta 
> and dev.
>
> I'd ideally like to have something that I run on a cloud server 
> (because uploads to my CDN will be much faster due to the slow 
> internet I have on the boat).
>
> I'm just looking to see what people in Lispworks land uses around this 
> before I reinvent the wheel.
>
> My current solution works well, but obviously now that I'm starting to 
> roll this product out into the real world I'd like my delivery 
> mechanisms to grow up a bit and be more robust. The main thing I'm 
> trying to force on myself is better branch management and commits (so 
> I can track them for release notes). It's been fantastic to move 
> rapidly with lisp and I've been hyper productive compared to stuff 
> I've used in the past, but I feel I have to build a few old 
> disciplines in a new way now. Being able to fix a bug, test it in the 
> repl and push a button that kicks a build out to the cloud delivery 
> within minutes of it being reported is fantastic, but I can see this 
> ending in tears one day.
>
> Regards,
>
> Eben Bruyns