# Trunk based development and continuous delivery with circleCI

**URL:** <https://discuss.circleci.com/t/trunk-based-development-and-continuous-delivery-with-circleci/47511>\
**Category:** Deployments\
**Created:** [March 21, 2023, 8:39am UTC](https://discuss.circleci.com/t/trunk-based-development-and-continuous-delivery-with-circleci/47511 "2023-03-21T08:39:58Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![atmosx](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/atmosx/32/27496_2.png) [@atmosx](https://discuss.circleci.com/u/atmosx)\
**Post date:** [March 21, 2023, 8:39am UTC](https://discuss.circleci.com/t/trunk-based-development-and-continuous-delivery-with-circleci/47511/1 "2023-03-21T08:39:58Z")

</div>

Hello,

Recently our team moved to trunk-based development to deliver production features faster.

We are using a monorepo the [path-filtering](https://circleci.com/developer/orbs/orb/circleci/path-filtering) and the [eddieweb queue](https://circleci.com/developer/orbs/orb/eddiewebb/queue) orb to manage workflows. The workflow on a high level looks like this:

1. PR in `main` is merged by an engineer and circleCI gets triggered
2. The queue orb will check if the job is queued or not by talking to the circleCI API
3. Run the path-filtering orb and trigger the respective workflow

The problem is that some times in step-2, the queue won’t manage two PRs that were merged within 90 seconds (some times more than 90s). There’s no guarantee that the VM to run the workflow will spin up in 5s or 30s. The race condition triggers two workflows that run in parallel instead of running serially.

Are there any circleCI facilities we could use to solve the problem?