What are the options and best practices for deploying the “breaking changes” in the index structure along with a new version of the application?
I have found another related thread:
It suggests preparing new index in the CI pipeline and move it to the production index as soon as the client web app is deployed. That sounds fine, however I have several doubts. I understand that no single approach fits all the apps, however I would be grateful to hear for generic suggestions and proven-by-practice solutions of the experienced Algolia developers.
- New version of the app may need re-indexing the data besides changing index settings. I don’t feel comfortable with putting my indexing code directly into the CI pipeline. My backend code is responsible for fetching the data and incrementally indexing it into Algolia, and I’d like to avoid duplicating this indexing code in the CI pipeline.
- What if I need to support two versions of the client code simultaneously (in case of the native app, not a web one)? I guess I have to maintain two indices. Any specific practical suggestions here?
- What are the cons/pros of storing the index settings/rules/synonyms in GIT along with the code and applying them to the prod index in the deployment pipeline?
These questions are quite generic. For the sake of specificity, let me describe my particular case.
- Serverless web app based on the Firebase Cloud Functions.
- Frontend served from Firebase Hosting, with InstantSearch.js.
- Data for indexing is fetched from the Firebase Realtime database.
- One index with rarely changed structure, but occasional changes are expected in the future as the app evolves.
- Data is quite stable, it does not change frequently. Only in case any mistake is found.
- New records can be added (“published”) once per several months.