How do I design a CI CD (incl. continious deployme...

# compose-desktop

[Christopher Hübner]

How do I design a CI CD (incl. continious deployment) process for desktop applications?

[mikehearn]

There are several factors that go into this related to code signing, automatic update, and cross-building.

There's an easy way and a hard but cheaper way. The easy way is to buy the tool my company produces, which is designed for exactly this problem and has built in support for everything you need. We have customers successfully deploying from CI/CD multiple times per day. The main relevant features are that it can take your input JARs and produce packages for Win/Mac/Linux (x86 and ARM for all platforms), which know how to update themselves including synchronously on startup (good for QA/testing), and it offers a JAR on Maven Central for controlling the update engine. It also knows how to drive the cloud signing services that Windows CAs now offer for code signing in CI/CD, it can also drive Apple's signing and notarization process, and it can do all that from ordinary cheap Linux workers. Finally, it has recently added a lot of optimizations to cache signatures because unfortunately Windows certificate authorities are trying to squeeze people by charging very high per signature costs when using the cloud CI.

I wrote a blog post here that goes into how to configure Conveyor for CI/CD, it's a commercial tool with built in support for Compose Desktop apps. The blog post is about Electron but the same advice applies to JVM apps also.

https://hydraulic.dev/blog/21-shipping-electron-apps-from-ci-using-hsm-certificates.html

Then there's the harder way, which is to use the open source Compose related tools. There are other users in this channel who can guide you there, but generally expect the following:

1. You'll need to have Windows, Mac and (if you need it) Linux build workers. Expect to pay at least 10x more per second for Mac cloud CI workers.
2. You'll need to set up the code signing yourself. The cheaper way (also works with Conveyor) is to buy from the CAs a USB signing token and plug it into a worker whose hardware you control. Some cloud CI services make it easy to add custom workers. If you buy a cloud signing service you'll get ordinary credentials you can stick in environment variables etc but watch out for signature costs because it's easy to end up doing thousands of signatures in CI/CD pipelines if you deploy regularly because you generally need to sign every EXE and DLL inside your package. Conveyor has a caching system to reduce costs transparently but other tools usually don't.
3. You will usually be on your own when it comes to automatic update. Expect to have to implement your own system. This is very awkward and usually represents most of the complexity budget of going this path (e.g. because you can't overwrite files that are in use on Windows, on macOS there are kernel bugs to do with updating code in-place that require workarounds, you may want delta updates to save bandwidth+time and so on).

[mikehearn]

All the above assumes a commercial use case. If it's open source then Conveyor is free, and you can use self-signed packages (which have a terrible UX that requires administrator access on Windows, but open source apps are often meant for devs who don't care about that).