pantsbuild / example-django

An example repo to demonstrate Django support in Pants

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Dependency of one service on another while deploying

sandeepbprm opened this issue · comments

Hi,

I am implementing a DRF based SAAS application based on the concept and structure mentioned in this repo. My application has apps which handles the necessary models, serializers and views. It also has services which depend on one or more apps. By this i mean that an app can be used in one or more services which in turn deduces the fact that a database can be shared by multiple services. I have encountered 2 edge case which i need to solve before moving it into production.

Case 1: How do we handle the deployment of services dependent on a common app when the database schema related to the app changes? Let us say, If serviceA and serviceB uses the appC which connects to databaseZ. Both the services are deployed separately using pex files. If i make some model changes in appC and initiate the deployment of both services A and B. If the deployment of serviceA happens fast, it makes the necessary migrations in the databaseZ which might effect the business logic in serviceB and results in the failure of requests to B.

Case 2: How do we handle race conditions in accessing databaseZ by both services? Let us say, serviceA is writing a transaction to databaseZ and serviceB also wants to write to the databaseZ. Won't this result in a lock and make serviceB wait.?

Please help me understand how to handle the above 2 cases and let me know if i have missed some detail while implementing.

Thanks,

In my experience it may be necessary to split model changes into two or more steps, where you simply introduce the migration first, then the model change and app code, when adding features. For removing you go in reverse, deploy the change that removes all references to the model field first (perhaps after deploying an initial migration changing a required field to optional) then when there is no code using the field go ahead and deploy the migration that removes it from the DB.

That is, separate DB migration changes from app code changes so that they can co-exist without issue.

These aren't Pants or Django questions per se, but general software engineering and system design questions. For both your cases I recommend studying the locking properties of your database system, and the general principles of backwards-compatible schema design.

I will close this as general. But feel free to open issues that pertain specifically to Pants (bugs, feature requests etc.)