You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reason it's in zanzibar is because it's very easy to break backend when making changes in zanzibar.
The backend module is responsible for WRITING configs to disk.
The codegen module is responsible for READING configs from disk.
If you make any changes to codegen related to configs your likely to break backend.
If you do move the backend thing out; you should evaluate if you can call INTO uber jenkins from travis and effectively run the test suite for backend with the "new version" of zanzibar.
When we were actively developing and working on backend & codegen we would often make changes to codegen and then not update backend.
whomever was unlucky enough to update the version of zanzibar in backend had to make all of the unrelated changes in one go :(
@Raynos Thanks for the insights. The team is aware of the tradeoff of the proposed change.
The tempo of config changes has slowed down compared to the earlier development period, which makes not having backend in zanzibar more manageable that it used to be. Also, the team working on internal projects sometimes needs to make awkward changes to work around the fact that backend is open source.
Your comments are absolutely on point, we will need to be more conscious about the impact of future zanzibar changes and improve team communications to ease the version bump process.
backend/repository
, as an application relies on Zanzibar, does not really need to be part of Zanzibar.The text was updated successfully, but these errors were encountered: