Boulder Deployment (which Release/Branch/Commit to use?)


#1

Hi Veryone,

as @cpu mentioned in another thread it is not recommended to use the release zip files but instead go with the git repository. We are looking into deploying boulder internally and have made some successful tests with the docker environment. However, we were not able to get the latest master up and running so we also reverted to testing with the zip file from february. Is there some way to figure out which branch/commit to use for deployment?

Boulder looks pretty good to us and the wide availability/integration of clients is a big plus for us here. We understand that your primary focus is on your internal deployment and I guess you also not keen on exactly tagging which versions you are running in production yourselfs. Any information would be appreciated!

Regards
Rudi


#2

Boulder deployments to Let’s Encrypt infrastructure are announced in their status page, complete with the git commit hash they are upgrading from and to.

https://letsencrypt.status.io/pages/history/55957a99e800baa4470002da

The most recent commit currently deployed is:


#3

Hi @rbott,

That’s correct - we haven’t been making release zip files for quite some time. I don’t recommend anyone use them.

I’d be happy to help you try and diagnose the problems you’re having with the master branch if you open an issue on the Boulder repo with the errors/problems you’re facing.

Like @Patches mentioned (thanks!) we announce our production updates on the status page. The basic workflow is that on every Tuesday* we merge the master branch into the staging branch and deploy staging to the staging environment. On every Thursday* we merge the staging branch to the release branch and deploy release to the production environment.

So whatever is in the release branch should track the production environment.

* - We do occasionally skip releases when there are regressions or during holiday seasons. There wasn’t a deploy this week and there won’t be one next for instance.

Hope that helps! We’re certainly open to improvements to our release management process but it has been a low priority. That’s mainly because there are few external Boulder deployments that we know about. Hearing more about what you’re using Boulder for and how we can cut releases to better suit your needs might help adjust the priority :slight_smile:

Take care,


#4

Thanks @cpu and @Patches for your quick answers!

We’ll take a look at the release branch after the holidays and we’ll publish all our findings (or open bugs if required) - after the holidays :slightly_smiling_face:


#5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.