{"id":1439,"date":"2022-03-13T17:23:40","date_gmt":"2022-03-14T00:23:40","guid":{"rendered":"https:\/\/bullyrooks.com\/?p=1439"},"modified":"2022-05-28T10:37:06","modified_gmt":"2022-05-28T17:37:06","slug":"kube-cloud-pt6-synchronous-contract-testing-conclusion","status":"publish","type":"post","link":"https:\/\/bullyrooks.com\/index.php\/2022\/03\/13\/kube-cloud-pt6-synchronous-contract-testing-conclusion\/","title":{"rendered":"Kube Cloud Pt6 | Synchronous Contract Testing Conclusion"},"content":{"rendered":"\n

This course absolutely warrants a final thoughts page. Contract testing can be quite powerful, but it has to be done correctly<\/strong> and that means that you need quite a bit of engineering experience not only from a software development side, but also from an operations CICD side as well.<\/p>\n\n\n\n

First the downsides<\/p>\n\n\n\n

<\/div>\n\n\n\n

Support<\/h2>\n\n\n\n

Pact has been in active development for awhile. Its implementations are sprawling. There are several libraries that have overlapping functionality that are in various states of maturity. The documentation is okay, but its not clear what best practices are. Additionally, there are loads<\/strong> of proof of concept demonstrations available online (and I’m probably adding to the noise) with differing levels of ‘good’ implementation and depth. A lot of the demos out there are out of date and don’t work well with the more recently libraries. This has safely been the most time I’ve spent (2 weekends) trying to get something working and documented.<\/p>\n\n\n\n

I’ve worked with the pact team before and they’re knowledgeable and supportive, but this project feels like its a little of ‘everything for everyone’: lots of configuration but little in the way of convention (defined best practices and the framework guiding you to them).<\/p>\n\n\n\n

Engineering Maturity<\/h2>\n\n\n\n

If you work in an organization where the CICD pipeline is owned by another team (usually called devOps, but there’s no interest in software development), you’re going to struggle being successful implementing contract testing with pact. I had to backup and rethink my workflow a few times. If you have siloed software engineering from operations, you’re going to get frustrated and it wouldn’t surprise me if an operations team that is working with engineergs trying to implement pact says something like ‘go off and figure it out and then tell us what you want to do when you have a plan’. <\/p>\n\n\n\n

It didn’t help that pact’s guidance (tags vs environments and releases) has evolved as well and some of the tools support their new model (stick with the docker cli) and some tools don’t (maven plugin). <\/p>\n\n\n\n

I literally kicked off probably 100 github action workflows tinkering with the pipelines working on this.<\/p>\n\n\n\n

Production Readiness<\/h2>\n\n\n\n

You will probably get to a point with pact that you are literally blocked. You can’t deploy a consumer because the provider doesn’t support the contract and the provider can’t deploy because it can’t fulfill a contract. Will you have the experience to untie that knot? Will you have to ‘delete the integration’ and start over (I’ll admit, I did it a few times)? Will you have people in your team supporting you (devOps) or people demanding that you tear down contract testing (usually engineering leadership)? Can you slowly roll it out and harden process against the edge cases? Will you be able to implement rollback? If not, you could bring your engineering organization to a standstill.<\/p>\n\n\n\n

Now the positive side<\/p>\n\n\n\n

Proactive vs Reactive<\/h2>\n\n\n\n

I prefer contract testing so that we can prevent issues in production before we have to react to them. If I can prevent a team from delivering a breaking change and also inform<\/strong> them of why its a breaking change and which service it impacts, I can then point them to the right people to talk to to see how to fix the issue.<\/p>\n\n\n\n

This actually saves time in the long run and the costs of multi team war rooms trying to figure out why we’re losing money by the minute. Those get expensive really fast.<\/p>\n\n\n\n

Improved Communication<\/h2>\n\n\n\n

Its a little counterintuitive since a system is sitting in the middle of your CICD pipeline ‘replacing’ a conversation that should have happened. However, in my experience software teams (especially those empowered by microservice development to release early and often) are not doing the due diligence they should have been doing to understand systemic impacts of service releases. <\/p>\n\n\n\n

Pact will probably trigger conversations about service governance best practices like<\/p>\n\n\n\n