3 ms·
You can also design software A to produce both G1 and G2 side by side, deploy it, and then develop new software B against G2, submitting bug reports to project
by Joeri 9y ago
You can also design software A to produce both G1 and G2 side by side, deploy it, and then develop new software B against G2, submitting bug reports to project A when there’s a problem detected in G2.
If you’re doing the multirepo strategy it’s best imho to make the projects truly independent, as if they were developed by different companies. That way every project only needs to think about its own dependencies and consumers, and how to do migrations, without needing to have the big picture mapped out.
- geocar 9y ago> You can also design software A to produce both G1 and G2 side by side This can be impractical if G is a database table that is very large. > it’s best imho to make the projects truly independent, as if they were developed by different companies. One of our systems might cost £300k, so completely desynchronising them so that code paths can build both G1 and G2 simultaneously (allowing B to develop separately) means "simply" doubling the costs. That might put our team at a disadvantage against someone who figures out another way.
- Groxx 9y ago> This can be impractical if G is a database table that is very large. If this is true, you have no choice, and must run things side by side while you convert to G2. Or shut everything down to make the migration atomic, which is increasingly not an option.
- geocar 9y ago> you have no choice It depends on your database. If you imagine a simple postgres or mysql server and an "alter table G..." then you're right. If (however) G1⊂G2 then a document store or a column-based database can usually partition the table somehow.
- gwenzek 9y ago> This can be impractical if G is a database table that is very large. Unless if the new format G2 is a super set of the old format G1. Read protobuffers best practice to know more about this.