CODEWITHSUNDEEP
continuous-integrationcontinuous-deployment
guettli
guettli

Reputation: 27816

Aligning frontend/backend CI and CD

We have two git repos:

Example:

  1. Developer pushes code to the frontend repo. Frontend has version 0.5 now
  2. CI tests the changes against backend version 1.1.
  3. Everything is fine, all tests pass.
  4. The frontend code gets deployed to the production system
  5. There is a major failure, since the production backend is still on version 1.0

How to avoid this?

Update

In the package "world" you can define dependencies. For example with rpm/dpkg/pip/npm. In above frontend/backend scenario you would need to define a dependency, too:

Frontend v0.5 needs backend v1.1.

Upvotes: 2

Views: 1472

Answers (1)

Carlos Robles
Carlos Robles

Reputation: 10947

If you want to achieve full CI/CD then contract testing and/or functional testing are an absolute must.

Whether the system follows a more strict design by contract, what is clear is that the is a contract between parts, a mutual agreement on how the subsystems communicate, for example, what are the API responses from the backend that your fronted requires.

If one consumer requires, for example, a new schema for one specific API, or if one producer is updating the schema of one specific API, as you are describing, things will crash. That's why the contracts have to be validated every time that any of the subsystems are updated.

How to do this?

  1. First, you need to think about your development workflow.

    • Some people enforce consumer-driven contracts. This simply states a philosophical position that advocates for putting the consumers of APIs at the heart of the design process.
    • Some others will prefer to let the backend drive.
    • In some cases, this is unpredictable, and consumers or providers could need to drive the change in different moments, or in certain microservices mesh, consumers are producers and producers are consumers.

  2. You need to have in place any tool for any of API testing, functional testing, contract testing. Very normal ones, that have given me a lot of peace of mind, are REST-Assured, and Runscope (that now belongs to Blazemeter, so you can leverage API monitoring, functional testing, and many other features). Also, I didn't use them, but you can look into pact.io and pactflow.io, and some people seem to have good results doing consumer-driven contract testing with Postman and in general continuous API testing with Postman with the help of newman

  3. And finally, implement the testing in your CICD. Depending on what is your workflow, and your tools available, you will need to

    • decide where to keep the contracts, this can as schemas in one of the repos (i.e the frontend, the backend) or in a separate repo just for API schemas or test description, or in the tool itself.
    • decide how to run the tests. For this, since you are already running tests (I imagine at least unit/integration) in your CI/CD pipelines, you will just need to add the needed steps for also validating all contracts whenever any subsystem is deployed. So it will not go to production if any of the other subsystems are not in the required version, producing the expected schemas.
    • update your schemas FIRST, whenever one of the subsystems is using new requirements. I.e in your case, frontend needs backend version 1.1, so when you are writing the changes in the frontend, you already know what are the changes, so you can update the schemas used in the testing. When deploying to any environment, the deployment will succeed only in the environments in which the contract test passes. I.e it may work in sandbox/dev/QA environments if backend 1.1 is already there, but then if in production is not there, the CICD will stop since the contract test will not pass.

Upvotes: 2

Related Questions