CI/CD deployment to prod questions

[Raid55]

I apologize is this question is unrelated to openFGA, but it would be helpful to understand the best practice or be pointed in the right direction where I can read more about this without the anxiety of my "best guess".
I am building out our authz system using openFGA and I am nearing completion of a POC. However there are a few things that I could use some help on that i could not find on the Discord or on the github disc.

Being an amateur infra engineer, does anyone have solid pointers to some good reading around deploying OpenFGA in production? This would involve:

• Creating the initial store through CI/CD and updating the store_id for the sdk to use
• Running model migrations through CI/CD and updating the auth_model_id for sdk to use
• Keeping track of auth_model_id's in case a revert is required.

Right now my thought is to have a job install the CLI and run a "temporary server" connected to the staging/prod permissions database (psql) and make the changes. Once they are made, store environment variables as part of the backend docker image, thinking that if we reverted the auth_model_id would still be the previous one, regardless of if a new schema was created on the db. I am also thinking that a k8s job could run to handle schema migrations and env variable management (restart backend pods with new vars).
I am hoping to find a solution that will not be a burden on other engineers or the devExp as they make changes to the model and that will prevent mistakes from being made...but have a plan for when they eventually happen.
Any help or links to some third party libraries that can help with this type of mgmt in general is most welcome.

[chahat-agarwal]

@Raid55 Hey, did you by any chance identify such pointers? Even I am looking for the same.

[bittrance]

I'm facing a similar problem in that I want to use an init container to automatically install a new model when it is changed. Currently, I'm keeping the auth model hard-coded in my source code as this makes for good dev exp and allows integration tests to apply it during setup.

I have resorted to inserting a type with the hash of the auth model in the name (i.e. {"type": "hash_431241234124"}. I'm calculating the hash from the model itself because this works for a dev in the process of crafting a commit, but the same strategy would work in a cont'd deploy using the git sha.

Procedure:
If our state has no auth model id, install auth model and write the id to db and exit. If not:

1. request auth model with the current id from db
2. Extract hash from hacky "hash type definition"
3. Calculate hash on auth model included in the deployment.
4. Exit if hashes are identical.
5. Update the auth model in openfga
6. Store the new id in db

This makes sense in a devops setting. When we need to change the model, we deploy a "dual model". Once all instances have been rolled over to the new auth model, we can migrate the permission entries and, if necessary, finish with deploying a new "singular model" which drops support for the old auth model.

This works well for a smallish microservice architecture built from a mono-repo where the devs have embraced devops.