What a perspicacious observation! So many people forget that eventually you have to debug, and if all you have are code breakpoints and printf statements, it can be difficult (and sometimes nearly impossible) to debug things like exceptions, code profiling, nested interrupt issues, and more. There is a way where you can take the output of a CI/CD pipeline and debug it in Embedded Workbench. If you are already developing code in Embedded Workbench, you can just take the .out file output of the CI/CD and replace the one in your project's directory structure. If your build configuration is, say, "Flash debug", then your project directory will have a folder called "Flash debug" and under that will be a directory called "Exe" that contains the .out file. On the other hand, you can take the .out file from your CI/CD pipeline and in the Embedded Workbench choose the Project menu, then Create New Project and choose Externally-Built Executable as the type. There will be a how-to document that pops up and tells you how to add the .out file to the project. Once you set the device type and the hardware debugger in the Project settings, you can do source-level debugging of the output file (assuming the directory structure of the source on your machine matches the structure on the build pipeline). If you have any issues, you can contact us at support@iar.com. By the way, I am running a webinar tomorrow called "Practical Debugging Techniques" that shows how to leverage some of the debugging functionality in our tools to do things like finding hard faults, stack overflows, and several other common programming glitches!

You're correct, Windows Server is an alternative way to approach CI/CD. My intention was to approach CI/CD in ways that are considered "lighter weight" than a full server in order to minimize overhead/expense with adopting more modern build techniques...but you're right, it is easier to setup! On the deployment side, there are a number of ways that CD can be performed. The ones that we see used most often are AWS Code Deploy, GitLab, Bamboo, Team City, and Jenkins, though there are many more. After passing all the checks, the code is typically encrypted and uploaded to a CD server to be either auto-magically deployed to the client devices (e.g. in the case of a critical security update), or a notification delivered to the customer that an update is available. Usually that upload process is automated, but the actual mechanics of how that happens varies depending on the CD strategy you choose to employ.

Hi Kevin, to do what I demonstrated, you would also need a license of BXARM (IAR Linux Build Tools for Arm) for your CI/CD server. If you'd like, we can discuss it further offline.

Hi Niall, my original paper (with footnoted reference) can be found here:
https://www.iar.com/knowledge/learn/code-quality/move-fast-and-break-things-not-so-fast-in-embedded/

Hi Stefan, the simple (and perhaps overly simplistic) answer is that a self-hosted runner is a lighter-weight way to accomplish most CI processes. Jenkins typically requires more resources, but it also has far more plugins that allow you to customize your CI/CD process to your exact needs.

Yes, there are always, ALWAYS more things to learn...but to me, that's what makes being an embedded engineer fun and exciting!

I've seen a few ways to do it, but none of them are elegant. One way that I have bookmarked is this: https://zpz.github.io/blog/connect-to-localhost-from-container/

Hi Gerhard, you are absolutely right - my mistake. Apologies for conflating the two!