Структура репозитория для исправления исходных загруженных источников

Question

У меня есть веб-приложение.Приложение имеет два источника кода:

• source1 - это выпущенное веб-приложение на Java, которое необходимо вручную загружать через защищенный логин веб-интерфейс
• source2 - это модификации и дополнения(xml и txt) в source1

Готовое приложение представляет собой комбинацию source1 и source2.Source1 перезаписывается.

Source1 - это код, который я не касаюсь.Это выпущено как почтовый файл, который я должен извлечь.Каждые несколько месяцев есть исправление (также zip).Через пол года выходит новый мажорный релиз.Основные выпуски несовместимы, поэтому каждые полгода мне придется сохранять старую версию и начинать заново.

Source2 - это код, который я изменяю, или включает дополнения source1.Source2 постоянно развивается и изменяется.

Я хотел бы использовать CI / CD для создания готового приложения и его развертывания на сервере.Я хотел бы получить рекомендации о том, как лучше всего структурировать свой репозиторий / репозитории?

Answer 1

Есть много способов структурировать это, так что это рекомендации:

Если вы используете git:

• Держите одну ветку git только для приложения source1. Каждый коммит в этой ветке должен быть просто обновлением файлов source1, а любой коммит должен содержать только файлы sourc1.
• Сохраняйте разные ветки для вашего приложения, которые содержат ваши изменения как отдельные коммиты.

                  . < src2 branch
                  |
                  o src1+2-1.1-1
                  | 
 src1-branch > .  o src1+2-1.1-0
               | /|
               |/ |
     src1-1.1  o  | 
               |  o src1+2-1.0-1
               | /
               |/
     src1-1.0  o

Эта структура позволяет вам отслеживать то, что изменилось между версиями source1, и вы можете в любой момент снова начать с версии src1 и выбрать свои изменения поверх нее.

Для CI / CD просто пересобрать / заново развернуть на толчках в ветке src2.

Answer 2

Я думаю, вы хотите что-то вроде

• создайте ветку для source1 - фиксируйте релизы и патчи здесь по мере их получения, чтобы состояние ветки всегда совпадало с последним выпуском, который вы получили
• сделайте вашу основную ветку из source1, и зафиксируйте ваши коммиты source2 здесь (или добавьте ветки для функций, а затем объедините их здесь)
• настройка CI и CD из ветки source2 / master
  • (возможно, стоит настроить какой-то CI на ветке source1, просто чтобы убедиться, что его тесты нормально работают на вашем сервере сборки, прежде чем вы вносите какие-либо изменения, но это нечасто, поэтому вы можете просто отключить их вручную).

Тогда коммит source1 всегда является родителем master / source2, и когда вы получаете обновление в ветке source1, вы можете просто попробовать git merge сделать это в master / source2. И это может просто сработать: если нет, и вам нужно начать заново, то переименуйте вашу старую главную ветку в сторону (или просто сделайте тег), затем возьмите новую ветку master из source1 и cherry-pick или перепишите все свои фиксирует это, исправляя их для новой версии source2.

Могут быть более умные решения, но это дает вам историю source1 и разумное представление работы source2, которую вы проделали поверх нее. Я не могу сказать, справится ли git merge с основными изменениями в source1; коллеги в восторге от его сверхдержав, но я сам имел смешанный успех, но это стоит того. Это не дает вам ни одной ветки со всеми вашими выпусками source2 в тот момент, когда вам нужно вырезать новые ветки из source1, но вы можете отслеживать их с помощью тегов.