Theatre

Embedded DevOps: Hardware in the CI Loop and the Transformative Power of Sharing Work-in-Progress

Watch Now

25:45

EOC 2025

Login to Watch

Darwin Sanoy

Darwin Sanoy has spent his career in strategy, architecture, engineering and coding for provisioning and operations automation including scaled virtual platforms. His early career was in enterprise IT automation, mid-career was running a solo business for enterprise automation training and the last decade has been focused on Cloud, DevOps and Agile. He is constantly reading on topics in and around how technology can be leveraged to create business and customer value. Darwin is ISO 26262 Functional Safety Certified, Enterprise Architecture certified, and AWS DevOps Pro certified. He also loves volunteering at Economic Mobility Nonprofits that bootstrap people into tech careers to improve their lifetime earnings potential.

View full profile

Topics Covered

Security Testing Tools Agile/Processes

Theatre

Embedded DevOps: Hardware in the CI Loop and the Transformative Power of Sharing Work-in-Progress

Darwin Sanoy

25:45 EOC 2025

Darwin Sanoy

25:45

It took 36 years for humans to be able to dominate the computer game Tetris and it happened because of a need that forced global sharing of gaming expertise.

Traditionally, embedded software development has been tethered to workstations due to the necessity of interfacing with embedded hardware. However, as technological advancements increasingly liberate embedded developers from desk-bound constraints, the ingrained habit of work-in-progress isolation persists. This deeply rooted practice makes it challenging for teams to benefit from shared wisdom and collaboration.

Collaborative innovation is not possible if work-in-progress is not shared as it is being done. If you reflect on your habits to gain expertise, you might notice that you're doing those searches "while you work". Sharing work-in-progress also allows other sources of expertise to be a part of your expertise searching such as AI and automated testing.

Things you will learn:

That sharing work-in-progress is foundational to benefiting from collaborating agents.
Software engineering expertise sharing through code reviews.
Shared software manufacturing expertise sharing through CI automation.
Automated sharing of costly physical hardware resources.
A culture of continuous wisdom transfer grows internal talent.

This session is about breaking free from the inertia of isolated practices and transforming work-in-progress into a shared, collaborative activity that accelerates innovation.

1 / 4

Please log in or create an account to test your knowledge and see the answers.

According to Darwin Sanoy, what is the primary benefit of sharing work-in-progress in embedded development?

A It allows managers to strictly control who makes code changes and when.

B It enables collaborative expertise — including other humans, AI, and automated testing — to participate and accelerate innovation.

C It reduces the need for automated testing because problems are found by reviewers.

D It ensures every developer must have a full copy of expensive hardware on their desk.

E It primarily serves as a historical record of development decisions for audits.

What behaviour does 'environments-as-code' in GitLab enforce for branch-based development?

A Create a lifecycle-managed environment when a branch is created, update it on pushes, and destroy it when the branch is merged or deleted.

B Keep the environment running indefinitely after creation so developers can reuse it across projects.

C Only create environments manually via the GUI; they cannot be created or destroyed by CI.

D Automatically snapshot a developer's local desktop and upload it to the cloud instead of deploying the environment.

E Require that environments be provisioned only on physical hardware and never on simulation services.

How does the GitLab Device Cloud handle real hardware in CI/CD pipelines, according to the talk?

A It duplicates hardware in the cloud so every developer gets a private copy of physical devices.

B It orchestrates a pool of real devices, allocating a device exclusively to a pipeline job and deallocating it when the job finishes.

C It requires developers to ship physical devices to a central data center before CI can run.

D It only supports simulated hardware and cannot manage physical devices across locations.

E It permanently assigns devices to a single project, preventing reuse by other pipelines.

What effect do compliance frameworks and policies in GitLab have on pipelines and merging, as shown in the demo?

A They add required CI jobs into the pipeline and can block merges if a policy (e.g., new vulnerabilities) is violated, while still allowing CI to run.

B They only produce passive reports and cannot affect pipeline execution or merge permissions.

C They always stop the entire CI pipeline from running whenever a policy is configured.

D They only apply at the individual repository level and cannot be applied at a group level before repositories exist.

E They automatically fix any introduced vulnerabilities so developers never need approvals.

Formatting help

italics	surround text with asterisks
bold	surround text with two asterisks
hyperlink	[hyperlink](https://example.com) or just a bare URL
inline code	surround text with single `backticks`
code block (multi-line)	wrap on its own lines with three backticks: ``` your code here ```
~~strikethrough~~	surround text with ~~two tilde characters~~
quote	prefix with >

Upvotes Newest Oldest

datamstr

Score: 0 | 1 year ago | no reply

Excellent presentation!

Partners & Sponsors

CodeSecure

atym

embedd.it

IAR

Become a Sponsor