# Deployments as devices move between dynamic groups

**URL:** <https://hub.mender.io/t/deployments-as-devices-move-between-dynamic-groups/7283>\
**Category:** General Discussions\
**Tags:** hosted-mender\
**Created:** [October 29, 2024, 5:48pm UTC](https://hub.mender.io/t/deployments-as-devices-move-between-dynamic-groups/7283 "2024-10-29T17:48:10Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![tbraunjones](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/tbraunjones/32/2169_2.png) [@tbraunjones](https://hub.mender.io/u/tbraunjones)\
**Post date:** [October 29, 2024, 5:48pm UTC](https://hub.mender.io/t/deployments-as-devices-move-between-dynamic-groups/7283/1 "2024-10-29T17:48:10Z")

</div>

We use a GitOps pipeline to provision Mender Device configuration (side note: would be awesome if Mender provided a [Pulumi Package](https://www.pulumi.com/registry/)!). This includes a tag `deploymentGroup` that is used to include the device in a dynamic group which are the target of deployments. To make it concrete, two commonly used `deploymentGroup`s are:

- `ExternalBeta`
- `InternalInventory`

It’s common that `InternalInventory` gets a newer version of SoftwareX than `ExternalBeta` (e.g. to have access to new manufacturing QA functionality).

When the device is ready to ship to a customer, our GitOps pipeline will set the `deploymentGroup` to `ExternalBeta` (among other configuration/tags). If a device is RMA’d, it will get put back in `InternalInventory` and we would expect that version of SoftwareX gets deployed appropriately.

What’s the right way to handle this in Mender? Our original approach/thinking was that simply having indefinitely running deployments targetting dynamic groups would allow us to move devices freely from one dynamic group to another and have deployments that would do the Right Thing. But after seeing the actual behavior and then re-reading the [docs on dynamic groups](https://docs.mender.io/overview/deployment#deployment-to-dynamic-groups) (“principle of guaranteeing a predictable”, “won’t take part in the same Deployment twice”), it doesn’t seem to be so simple.

We are on a hosted Enterprise plan.

---

<div class="post-metadata">

**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\
**Post date:** [October 30, 2024, 8:18am UTC](https://hub.mender.io/t/deployments-as-devices-move-between-dynamic-groups/7283/2 "2024-10-30T08:18:35Z")

</div>

Hi @tbraunjones,

From my understanding a combined approach of a long running deployment to a dynamic group, and a directed deployment - not sure if that is a commonly used term - to an eventually RMA’ed device.

1. a long running deployment to a dynamic group `InternalInventory`, which deploys the current software. This deployment is stopped and recreated with a new artifact upon each release.
2. upon RMA, I presume there is some process (which also triggers the new tagging), and during that you can create a deployment which just targets the processed device with the desired latest software. The API ([Mender API docs](https://docs.mender.io/api/#management-api-deployments-create-deployment)) offers a convenient way for that, by this configuration:

```auto
	name: device_id,	# Note: adding a real name here breaks the GUI, see MEN-6931
	artifact_name: artifact_name,
	devices: [
		device_id
	],
	all_devices: false

```

The reasoning is that step 2 covers the time between the RMA process, and until the next software release (which is step 1).

Hope that helps,  
Josef

---

<div class="post-metadata">

**Author:** ![tbraunjones](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/tbraunjones/32/2169_2.png) [@tbraunjones](https://hub.mender.io/u/tbraunjones)\
**Post date:** [October 30, 2024, 5:59pm UTC](https://hub.mender.io/t/deployments-as-devices-move-between-dynamic-groups/7283/3 "2024-10-30T17:59:26Z")

</div>

Thanks for the quick response. I’ll look into this. It sounds like burden is on us more than I hoped it would be. I was expecting to find what I see with other modern DevOps tooling where the approach is to configure a desired state and the tool reconciles differences with the actual state and does what’s necessary to get it into that desired state.