How to handle CI and reliance of deployments?
Lately I've been wondering. How do you guys handle slow CI-deployments and the reliance of updating both the front- and back-end at the same time?
We are using the gitlab CI, along with private runners. Usually they deploy around the same time, but in cases when one of them might not be caught by our private runner and use a shared instead, they will increase in build time, as resources aren't the same between the two.
Thus making, say, the front-end be deployed a lot faster than the back-end, meaning problems will arise with them not being compatible.
I know that I'd simply not remove old API-paths, but will still not work the other way around, if the front-end is deployed faster than the back-end. Which is mostly what happens. ☕
Deploy the backend first, in a non-breaking way (additional endpoint, duplicate fields rather than renaming directly, keep old paths, …). Then deploy frontend, then cleanup backend. So with the backend changes being non-breaking the old and the new frontend work (so while the old frontend is running, it will still work).
That's how we did it with continuous deployment to production (fully automatic). We never deployed both at the same time, always deployed backend first (non-breaking), if there were changes required in the frontend that needed adjustments in the backend
@kevcodez Ah, gotcha! I'll try to do something like that. Though, how are you making the process automatic?
@Mobilpadde https://kevcodez.de/inside-agile-product-development-series/11-continuous-integration-deployment/
@Mobilpadde Not sure If I get your question right because you're already using GitLab for CI, so it's just a matter of doing the deployment within GitLab as well.
As Kevin mentioned, always make your back end backwards compatible. If you are doing breaking changes to an API endpoint, version it. In your pipeline, deploy the front end after the back end successfully deployed.
Please sign in to leave a comment.