1

The application we have is a C++ Windows application. The project is in Visual Studio 2015.

I'm in the process of helping to move our build process to the cloud. We already have a system in place for our server-side components, built on Jenkins. I am trying to directly use the process in place as much as possible without having to request exceptions to the current infrastructure for us. (All pipeline Jenkinsfile based).

We have a regular build running when we check in on GitHub. However, the part where I'm completely stuck is how to handle signed builds in a CI environment, where technically each thing pushed to master could be shippable. The thing is for server-side components that could work, but for client side, that would be signing every single build, which is not something we want to do. (I would imagine Windows builds wouldn't sign every single binary for a build unless it was time for a release).

I've been reading up on git-flow, and it seems the things they suggest is to tag a release with a version, and we can pick up on that in Jenkins. However that seems a little fragile to me; I kind of wish we could tag a commit with "release this" and then it will go off and set the version for me, etc.

In other words, how do you handle CI for windows client builds when a release is needed? Do you have a button on Jenkins that says "build me a signed release build", or do you sign every single build, or how do you do it? Everything I've read up on CI/CD talks about server builds, but nothing touches client builds, especially ones that involve code signing.

Pouya Samie
  • 3,718
  • 1
  • 21
  • 34
Jonathan Lam
  • 23
  • 4

1 Answers1

0

One possibility could be using GitHub's Releases feature, which also has programmatic access. Which you could use in 2 ways:

  • manually creating the release in GitHub then picking it up programmatically in jenkins (eventually on a dedicated build) to extract the version info and performing the signing. If you don't want to use a dedicated build then you could check for a match between the current SHA and the most recent release's SHA and, if it's a match, conclude that it's a release build thus it's a signing one.
  • manually triggering release builds in jenkins with a custom script which could compute the version number and maybe other release-related info (potentially more reliable, as you say), perform the signing and then programmatically create the GitHub release (and maybe push the necessary binaries/assets to it).
Dan Cornilescu
  • 39,470
  • 12
  • 57
  • 97
  • thanks. it looks like there is no pure CI/CD methodology that can be applied to client builds. i guess i got hung up over having to introduce a "manual step" into this process but upon reflection I agree that I think it is impossible to do this exactly like server builds. thanks for pointing out the API for the release function, i think that would fit into the plan (push button for release, if build and deploy fine then tag release via github, then rev master for next release) – Jonathan Lam Jan 17 '18 at 09:28