Same release with distinct builds

Currently we use CircleCI to deploy our app. We deploy a dev, and have a wait stage and then a prod deploy. The builds between the two but the code commits are the same. As far as I understand releases and deploys, since we have separate builds and endpoints, we need seperate releases. The issue is that “propose-version” uses the SHA which is shared between the two. It is smart enough to not have them collide but the versions it creates are not intuitive. I manually changed it to be the SHA_ENV but then the UI has name length issues since before it knew it was an SHA and would shorten it. Has anyone tackled this and knows of good ways to handle this? It seems this feature was not designed around the concept of having the same release having distinct builds by environment. Any help or advice is appreciated.

I think you are looking for the “deploys” feature for releases:

Deploys are simply to deploy the same build to multiple environments. I want to deploy the same commit with unique builds to unique environments. Deploys do not contain sourcemaps.

Well, that’s quite interesting. I think I need to pass this on to the releases team then. /cc @mitsuhiko

We currently have the dist identifier to separate source maps within the same release. That’s what we can provide today. We are however investigating the ability to upload source maps in a way that they can span releases in the future. No concrete dates on that yet though.

1 Like

Can you provide docs or details on dist? That one does not ring a bell from what I have found so far. One other issue I am curious how it would be handled. As it goes now, the build script creates a release, builds dev, finalizes the release, then deploys. If I need to do prod, it creates another release, builds prod, finalizes the release, then deploys. I do not always build prod, so I would need to always finalize the dev build. If I go to a single release, with distinct dist or whatever it might be, can I append to a finalized release to add the prod sourcemaps?

@mitsuhiko pinging on the above, would love details on dist to figure out how I might utilize that. I have noticed the issue with my current approach of appending the env to the end of the release means that when we release prod off the same git tag, it shows no commits in that release as it assumes those to be only part of the dev release. This makes tracking a lot harder. This also means that if we release dev a bunch, and prod only once, all of those commits are never associated to anything but dev releases.