Having spent some playing, reading, and thinking, ...
# pact-broker
p
Having spent some playing, reading, and thinking, I'm still struggling to understand a couple of things that I hope someone can provide advice on. Firstly, I wonder whether this guidance about modelling long running deployments holds true with Releases? https://docs.pact.io/implementation_guides/jvm/provider/junit5spring Certainly in our circumstance, and probably most others, I'd argue that there is "an advantage to recording Provider v2 as being in production during the time period of the deployment". Being able to model the versions being rolled off and rolled on provides a convenient way to reference the interesting versions that the
can-i-deploy
tool could work against to answer whether a deployment is safe. Is the key concern here premature assignment of 'deployed' or 'released' before the actual deployment? Perhaps this is a nomenclature issue or your trying to maintain strict definitions of the vocabulary being used? The scenario modelling I've conducted over the past few days suggests that using
record-release
and
record-support-end
alongside a
production
environment does provide the general and backwards compatibility requirements we have during blue / green deployments. Well, issue 903 withstanding. However, even though it works, I'm not keen to follow an "anti-pattern" as the document suggests. Are there specific technical or roadmap reasons why this approach really shouldn't be used? If we do use Pact going forwards, can anyone advise what consumer selectors would be suitable for our "Can I deploy" goal? We use trunk based development and won't necessarily deploy the latest versions at any specific time, and certainly don't deploy every version to production. Perhaps an illustrative matrix could provide an example:
Copy code
+--------------------------+--------------------------+
| Consumer version         | Provider version         |
+--------------------------+--------------------------+
| 1                        | 1                        |
| 2                        | 2 deployed to prod       |
| 3 deployed to prod       | 3                        |
| 4                        | 4 want to deploy to prod |
| 5 want to deploy to prod | 5                        |
| 6                        |                          |                     |
+--------------------------+--------------------------+
Trunk based means branching selectors won't work. tags are deprecated(?), latest wouldn't work due to consumer@6 and provider@5. From https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors, it does appear that
{ "deployedOrReleased": true }
would be most suitable if not for requiring 'premature release of customer@5 and provider@4. However, in my project's existing nomenclature, these versions would have already been released by Maven... Want I want to obtain is assurance of compatibility between consumer@3, consumer@5, provider@2 and provider@4 to ensure blue/green would work?
m
Yeah, I don’t recall any (additional) intent/thinking behind why that advice was added there in the docs. If the deployment is truly longer running, then it would mean that if a new consumer came along to release that wasn’t compatible with the new API release transitioning in, then you’d have a problem.
If you’re happy recording and unrecording releases, I don’t see any harm
(potential bug aside!)
p
Thank you for getting back to me. Releases really did seem to work when spiking last week.
nice 7771 1