this part of docs is a bit confusing

and remove it from consideration when checking if an integrated application is safe to deploy.

And hey dude, thanks for all the brilliant questions. Are you capturing these anywhere? There is probably value in the moment as having an FAQ page with Dmitry atm 😅 and then feeding that into our docs. Would you be interested in chatting to one of our UX team members to see how we could have makes this docs journey less confusing for you? cc: @Shuying Lin

and thats why questions appear

• recording a deployment will undeploy all deployed application

thats understandable ( making something like “latest” )

• Unrecording a release wont unrecord deployments.

this would be nice to add to docs because it a little bit contradicts with

Copy code

and remove it from consideration when checking if an integrated application is safe to deploy.

( prolly both notes )

We'd want to quickly test it out first before adding to the docs, or get Beth to confirm. I'll have get a chance tomorrow, I've gotta get my head down and box off a couple of tasks today. ty Dmitry

Deployments and Releases are separate domain concepts, and doing something to a deployment does nothing to a release, and vice versa.

Deployments and releases model real life actions - when you deploy an application, the previous version that was in that environment is automatically undeployed IRL and in the Pact Broker. When you do a library/app release, it doesn’t stop any previous releases being available IRL, so we don’t update any previous releases in the Pact Broker.

I’ve updated the docs in the “differences between deployments and releases”

I’m confused about which bits contradict each other @Dmitry Munda

“Deployed versions” and “released versions” are very similar, but are modelled slightly differently in the Pact Broker. The difference between

record-deployment

and

record-release

is that •

record-deployment

is used to model the real life scenario where a deployment causes the previous version of an application to be replaced by a new version. It is used for APIs and consumer applications that are deployed to known instances. When called, it automatically marks the previously deployed version as undeployed. •

record-release

models the real life scenario where the release of a new version of an artifact does not cause the previously released versions of the artifact to become unavailable. It is used for mobile applications and libraries that are made publicly available via an application store or repository. When called, it does NOT change the status of any previously released version. “Deployed versions” and “released versions” are different resource types in the Pact Broker, and an application version may be both deployed and released. For example, a mobile phone application version may be recorded as deployed to a mobile device for automated testing in a test environment, and then recorded as released to an app store in a production environment. Deployments and release lifecycles are completely independent of each other. Ending support for a release will not cause a currently deployed version to be marked as undeployed, and marking a version as undeployed will not end support for a release.

how’s that?

use case - we have 3 components

• all 3 were deployed ( deployedOrReleased returns all 3 )

• 1 was marked as released ( deployedOrReleased returns all 3(+1 but still 3 ) )

• released component was marked as record-support-ended

will deployedOrReleased still return all 3 components ? (edited)

Yes, all 3 will still be returned.

@Dmitry Munda btw, I don’t hang out in the general channel because there’s too much going on. If you have pact broker questions, best to ask in the #C9VPNUJR2 channel

adding this

Ending support for a release will not cause a currently deployed version to be marked as undeployed, and marking a version as undeployed will not end support for a release.

makes everything clear

🌮 @Beth (pactflow.io/Pact Broker/pact-ruby) and thank you 🙂