What to call selector for currentlyDeployed+currentlySupported

[bethesque]

The Pact Broker now has the concept of "deployed" and "released" versions. A deployed version is "currently deployed" until another version is deployed over it. A released version is "currently supported" until "end support" is called. The CLIs for recording the release and deployment events are documented here: https://docs.pact.io/pact_broker/recording_deployments_and_releases/#recording-releases

An API that has both deployed and released consumer versions (eg. an API that supports a deployed UI and a released CLI, like Pactflow) needs to specify both "currently deployed" and "currently supported" consumer versions.

The selector { "currentlyDeployed": true } for deployed versions is already implemented in the Pact Broker. I am planning on adding { "currentlySupported": true } for released versions. I'd like a selector that encompasses both currently deployed and supported in one go, so that there can be one simple recommended way of selecting pacts, regardless of the consumer type. I'm having trouble thinking of a term that clearly infers both though.

In real life (ignoring Pact Broker terminology) one could use the term "currently supported versions" to mean "every consumer version in production", however, that (to me) doesn't cover versions deployed to test environments. It's debatable, but I don't think of something in a test environment as being "supported" yet.

I was thinking about { "inEnvironment": true }. That covers all the stages of deployed versions, but a real life "released version" of a piece of software is still technically available in that environment, it's just that a decision has been made that it's no longer supported (eg. Rails v1 is still available for download, but is no longer supported).

Any ideas?

[bethesque]

Giving it some more thought. Maybe I don't need a selector that covers both, because it would be covered by the "autoSelect: true" option in the "pacts for verification" query, which will would return the latest pact from the main branch + currently selected + currently deployed.

[pendsley]

I kind of like this take the best. Have a single selector that handles the recommended best practices (which would include the scenarios you laid out for Pactflow). Then, provide fine grained control for advanced users that want/need that level of control.

[bethesque]

Exactly. Just need to finally decide on what the selector should be for the "released+still supported" versions. I think I'll go with the "currentlySupportedReleases" option that Kyle suggested.

[abubics]

I suppose currentlyDeployed raises questions for me about where it's deployed. You could granularly say something is now deployed in dev or staging or prod (or any other named envs), and also when it's no longer deployed there. Those boundaries are often trivial to hook into.

currentlySupported could be shorthanded with a few strategies, e.g. "anything that's deployed in prod is supported", or "anything deployed in the last 6 months is supported" (all parameterised, of course). Otherwise, custom support registration needs to be added, like deploy registration is.

Another dimension to approach it from might be: what profiles of things are people releasing/deploying/supporting? An API or app may be released and deployed, but only the deployed versions matter for support. But a non-live-only tool, such as an SDK lib or CLI tool never gets deployed, and only releases matter for support. In that case, are there any general strategies that could be useful?

I'm inclined to start from a real-world representation, and then see if it can be simplified (e.g. to booleans for currently supported/deployed). It's not obvious to me that any approach is both intuitive and general enough for people to not need guiding materials.

[bethesque]

The docs for record-release might clear up some of your questions Andras.

Recording releases

The pact-broker record-release command should be called once an application version has been successfully made available in a production environment (eg. via a Github release, made available on an app store, or released to a Maven repository etc.).

record-release is generally only used for production environments. If you do use it for pre-prod environments, you will need to manually call record-support-ended when a version is either promoted to production or it is decided that the version will not be released, otherwise you will end up verifying pacts for unnecessary versions. If you have a pre-prod repository that you are sharing a library to, and you only care about verifying the pacts for the latest version in that repository, then record-deployment may be more appropriate for pre-prod releases.

[bethesque]

many consumer versions can all map to one contract version, and if a consumer version is marked as unsupported, it doesn't mark the entire contract as obsolete.

This is correct.

[bethesque]

I might release a lib to a dev environment, then non-contract bugs are found, and it never gets promoted, so it never gets released to prod, and never supported even internally.

Yes, exactly. The docs I copied above are meant to address that - do you think they make sense?

[abubics]

Yep, that makes sense. It's becoming another overloaded term (because of course it is) :P If I use semantic-release, not all of those versions will be marked as releases for the broker. So record-release is effectively a shorthand for "mark release as supported".

The docs make sense, but the relationship between release & deploy & support could probably be more explicit. It's only kind of hinted at in the second paragraph :) Mostly why I didn't pick it up in the first read.

[bethesque]

Thanks @abubics. I'll try and make that clearer.

[bethesque]

Now I'm even not sure about the {currentlySupported: true} selector.

Here's a real world example. Pactflow is a forked version of the Pact Broker, and supports the Pact Broker Client (a library that gets released via Docker, Rubygems and Github Releases). It also supports the React UI, which is deployed in a test environment as well as a production environment.

When Pactflow verifies its pacts, it needs to verify:

• The master version of the Pact Broker Client
• All released and still supported versions (ie. the ones that I as the developer of the client support) of the Pact Broker Client
• The master version of the React UI
• The version of the UI deployed to test
• The version of the UI deployed to prod

What should the selectors look like for that?

• { branch: "master" } (code already done)
  • The master version of the Pact Broker Client
  • The master version of the React UI
• { currentlyDeployed: true} (code already done)
  • The version of the UI deployed to test
  • The version of the UI deployed to prod

That leaves:

• All released and still supported versions of the Pact Broker Client

If the selector is

{ currentlyReleased: true}

it's not quite accurate because every version of the PBC is still "released", but not every one is "supported". If there are super old versions of the PBC that don't work with the latest version of the Broker, they're still released, just not supported.

If the selector is

{ currentlySupported: true}

then it's a bit confusing because, from an IT English language point of view, I'd say the "currently supported client versions of Pactflow" include both the prod UI and the prod versions of the client:

• All released and still supported versions of the Pact Broker Client
• The version of the UI deployed to prod

The term "currently supported" to me doesn't strongly imply either way whether it's a deployed app or a released app.

{ releasedVersionsThatAreCurrentlySupported: true} is just silly :P But that's what I'm trying to say!

Just to complicate things, I don't know if anyone would want to model releasing to a non-prod environment? Is there such a thing? Would someone want to verify a pact from a version between HEAD and a production release? If a version of a library was record-released to a non-prod environment, { currentlySupported: true} doesn't seem like the right term for it.

Totally over thinking this. But I just can't find terminology I'm happy with.

[solarmosaic-kflorence]

In real life (ignoring Pact Broker terminology) one could use the term "currently supported versions" to mean "every consumer version in production", however, that (to me) doesn't cover versions deployed to test environments. It's debatable, but I don't think of something in a test environment as being "supported" yet.

I agree. I would not consider sub-production deployments to be supported yet. I also think there is only one kind of release -- when you publish an artifact to the production repository -- so environments shouldn't factor into releases. Technically you could differentiate production vs. non-production releases through the semantic version, but from the perspective of the tool I think any release should be considered equal.

The term "currently supported" to me doesn't strongly imply either way whether it's a deployed app or a released app.

I agree, I think { currentlySupported: true } can encompass both deployed and released and supported. From a deployment perspective, the current deployment would always be supported, and from the release perspective it is supported when released until it is marked as no longer supported. This would mean there wouldn't be a selector for just "currently supported releases" (without deployments), but if you needed one you could also have { currentlySupportedReleases: true } I suppose.

[bethesque]

{ currentlySupportedReleases: true }

That's the best so far!

[bethesque]

Btw, the logic for the pact selectors and can-i-deploy all works exactly the same way it did with tags. It's just a more explicit way of labelling things.