In CI/CD how to manage dependency between frontend and backend?

Question

I\'ll describe my setup to make the problems less abstract, but they don\'t seem specific to my case.

Context

We have Python-Django backend and a VueJS fronten

Answer 1

Branch dependency for tests

Sometimes when we develop branch feature-1 in the frontend, it must be >tested against branch feature-1 from the backend.

In our current setup all the commits in the frontend are tested against the deployed backend (to avoid replicating the backend in CI, only the production API address is used), resulting in false tests results in such cases.

and

Backend integration tests

When a commit is done to the backend, it can break the frontend.

Currently the backend isn't tested against the frontend (only the other way).

In my current company, we have Django for frontend(FE) and backend(BE), each in a repository. we're following trunk-based development. We also use gitlab for CI/CD. I rolled out what you mentioned here and didn't feel awkward at all.

Relationship between the environments and this branching model.

|Branches|example|environment|

|master |master| staging|

|release-v*|release-v1.1.10|preprod|

Tag:

|Tag|example|environment|

|v< MAJOR >.< MINOR >.< PATCH >| v.1.1.10|Production|

Once branches/tags are created or any commit to the defined branches, gitlab will trigger an auto build/deployment.

The frontend has to be tested against the backend. we do that with feature branch.

feature/< branch-summary >

developers need to ensure the same feature branch name existing on both FE and BE.

An URL for each frontend/backend is generated for each deployment look like -fe.< domain >.com for frontend -be.< domain >.com for backend

eg: there is a feature/mytask in both FE/BE repos. The FE URL is mytask-fe.< domain >.com and BE URL is mytask-be.< domain >.com

You can use docker-compose but in my case, our application is deployed to kubernetes using helm. A bit further of this implementation, My FE and BE has an k8s ingress which is managed by traefik. The DNS record(for each URL) is automatically created in (by k8s DNS controller), the backend is using DB and Redis which are created every time a feature branch is created or changed. By the convention of feature branch naming, the FE knows how to connect to BE and the BE knows how to use its own DB and Redis.

eg: helm upgrade --install ${RELEASE_NAME} ...

the RELEASE_NAME is extracted from feature/< branch-summary > ( not exceeding 63 chars)

Other things, you may consider about initialize data for feature branch deployment. In my case

*)Developers will manage to populate data (maybe running a script as init container in k8s). If a developer pushes a commit to the same feature branch, this will trigger a re-deployment and all data of DB / Redis will be re-inited. Developer may need to re-populate data and QC may need to restart their testing from beginning of this feature.

*)to avoid creating too many resources in k8s and branches in gitlab repository. I setup a remove function in gitlab CI in order to delete a feature branch in the BE/FE repository which will trigger a deployment deletion in k8s respectively.