It seems to be more about project collaboration. I suggest 1) Program for interfaces, which will largely ensure the overall advancement of your project. The principle is also relatively simple, that is, Project B does not need to implement the specific implementation first, but decides with the two development teams of Project A which interfaces are stable and which are unstable. Unstable APIs should be reserved for later use. Implementation, so that even if ProjectB is updated frequently, it will not affect the coding of ProjectA. If all subsequent needs cannot be fully considered due to the capabilities of designers and architects, we should try our best to make ProjectB able to do so under the premise of brainstorming. Provide the most complete interface possible. 2) I’m not sure about your company’s internal project management standards. For example, whether you have done enough unit testing for ProjectB to ensure smooth integration with ProjectA. If not before, I suggest you test ProjectB at key nodes. To do some basic unit testing, countless painful lessons tell us that for a weakly typed language like Python, there will definitely be problems if there is not enough UT. 3) When 1&2 are solved, you can choose any way to release ProjectB, whether using rsync synchronization, docker release, or svn update. After each release, you can do an integration test to see the code quality. . 4) If the current planning of ProjectB is very poor, there is no stable API, and it often changes. If this is already an established fact, it is recommended that you encapsulate the ProjectB interface and provide a logic-oriented encapsulation, that is, between ProjectB and ProjectA Add an intermediate layer between them. ProjectA should not directly operate ProjectB, but operate the intermediate layer to ensure the code stability of A/B
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
It seems to be more about project collaboration. I suggest
1) Program for interfaces, which will largely ensure the overall advancement of your project. The principle is also relatively simple, that is, Project B does not need to implement the specific implementation first, but decides with the two development teams of Project A which interfaces are stable and which are unstable. Unstable APIs should be reserved for later use. Implementation, so that even if ProjectB is updated frequently, it will not affect the coding of ProjectA. If all subsequent needs cannot be fully considered due to the capabilities of designers and architects, we should try our best to make ProjectB able to do so under the premise of brainstorming. Provide the most complete interface possible.
2) I’m not sure about your company’s internal project management standards. For example, whether you have done enough unit testing for ProjectB to ensure smooth integration with ProjectA. If not before, I suggest you test ProjectB at key nodes. To do some basic unit testing, countless painful lessons tell us that for a weakly typed language like Python, there will definitely be problems if there is not enough UT.
3) When 1&2 are solved, you can choose any way to release ProjectB, whether using rsync synchronization, docker release, or svn update. After each release, you can do an integration test to see the code quality. .
4) If the current planning of ProjectB is very poor, there is no stable API, and it often changes. If this is already an established fact, it is recommended that you encapsulate the ProjectB interface and provide a logic-oriented encapsulation, that is, between ProjectB and ProjectA Add an intermediate layer between them. ProjectA should not directly operate ProjectB, but operate the intermediate layer to ensure the code stability of A/B
Package it into a module and install it directly into the project path, so you don’t need to install it again when modifying Project B
Install ProjectB in development mode in the environment of ProjectA, and then directly update the code of ProjectB without reinstalling it.