Code4i
Information about infrastructure and git #1077
-
|
Hi, we are discussion about the best configuration of our software and how to migrate to git repository. In this moment we have 4 or 5 library in our server with different source. One of this contains about the 90% of our software, we are speaking about 4.000 programs. Any suggestion is valid. Many thanks |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
What criteria are you using to divide up your programs into different repositories? You say have 4-5 libraries, so that would have been my starting point: have one repository per library. There may opportunities to divide those repositories further. I would try to identify islands of functionality that you can extract into an independent unit. You may need to do some development work to support this. If you have program calls crossing the repo boundary, you need to start thinking about versioning these interfaces, so they can change and be deployed independently. If you have a shared database, you might want to use SQL views and/or routines to formalise that DB access, so you can explicitly see what these external repos are reliant upon. I would sum this up as: keep source code together that needs to change together. If migrating code to a separate repo is not practical, then perhaps see if you can use subdirectories in a single repo to help you more logically organise your code. It's difficult to do with a monolithic system, and it's a problem we have been facing with our product. Hopefully you can find a way forward. Good luck! |
Beta Was this translation helpful? Give feedback.
What criteria are you using to divide up your programs into different repositories? You say have 4-5 libraries, so that would have been my starting point: have one repository per library.
There may opportunities to divide those repositories further. I would try to identify islands of functionality that you can extract into an independent unit. You may need to do some development work to support this. If you have program calls crossing the repo boundary, you need to start thinking about versioning these interfaces, so they can change and be deployed independently. If you have a shared database, you might want to use SQL views and/or routines to formalise that DB access, so you can explicit…