Support explicit "branches" and "environments"
complete
Beth
Tags are currently used to represent branches and stages. They are very flexible and non-prescriptive in order to support as many different organisations' workflows as possible, but some people find the flexibility confusing and might prefer a more prescriptive model. We could potentially support an explicit "branch" property on an application version, and a "deployment" resource.
This would require changes to all the Pact Broker client libraries as well.
Matt Fellows
complete
Matt Fellows
I can see some recent activity on this, so by way of a brief update, there has been significant movement on this in the past few weeks. Java, Golang, JS, Ruby, PHP, .NET are all up to date. We are working to finalise the work in Python in the next couple of weeks, and then we will be going back to review all of the documentation, workshops and other advice out there.
As always, you can keep up with the Pactflow roadmap and commitments here: https://github.com/pactflow/roadmap/projects/1
Beth
in progress
Beth
At the risk of spreading our info over too many places, I have created a Github Discussion about this, as it seemed like a better place to put technical information https://github.com/pact-foundation/pact_broker/discussions/382
Matt Fellows
To elaborate on this problem:
As a framework, Pact has taken the position of flexibility - we provide a number of ways you can do things so that you can "customise it to your situation". Tags and Versioning are the main facilities in the Pact Broker to do this. This is great, because we can model any workflow - Gitflow, GitHub flow, trunk based or whatever custom process are all supported if you can get your tagging and versioning sorted.
With all of this flexibility, however, comes a cognitive overload.
The types of issues manifest themselves in a few ways:
- The DSL and domain model becomes confusing, because tags are used to represent multiple concepts - e.g. environments, stages and features.
- We get a number of "my verification results aren't showing" issues/requests in our forums, and we have to explain the potential reasons for this (which is a steep curve for newcomers, but also is key to a successful implementation)
- The "matrix" view is something we need to refer people to quite often - I think this is a sign that our UX is failing us
- We actually have a lot of the tagging documentation under "Pact Broker -> Advanced topics" section - but really, to do CI/CD well with Pact, you must have a decent grasp of this
It's likely that most teams fit into one of the flows mentioned above (Gitflow, GitHub Flow or Trunk based).
I think an ideal outcome would be something like the following:
- Existing ability to use tags remains for both backwards compatibility, and the "20" case.
- First class support for the concept of "environments" and "features"
- Out of the box support for agreed "standard" release processes
- Documentation that strongly encourages one of our "standard" release processes