Решение проблем с версиями и построением

Question

Где я работаю, нам нужно переосмыслить способ разработки программного обеспечения и отслеживать каждую выпущенную версию. У вас есть предложения по решению наших проблем?

1. Мы разрабатываем на Windows, в C++ с помощью VS 2005 (и C++ Builder для некоторого интерфейса материала)

2. Мы используем GIT, но в худшем из возможных способов можно себе представить. Мы несколько открыты для перехода к другому источнику контроля.

3. У нас есть 40 + встроенная DLL. Многие из них могут часто обновляться.

4. У нас есть несколько совершенно разных проектов, которые зависят от этих DLL.

5. Мы поставляем более 100 систем в год, каждый из которых требует специальной конфигурации. Большинство также требует пользовательских патчей. Мы стараемся как можно больше вернуть эти патчи в основной багажник, но вилки неизбежны.

6. Если через несколько лет мы должны обновить систему клиента, мы сможем вернуть код, используемый для этой версии, и все параметры среды. Нам нужен способ подтвердить, что этот код соответствует двоичным файлам в системе клиента. Возвращение кода должно быть настолько простым, насколько возможно, и, возможно, за исключением компилятора, у нас должно быть все необходимое для компиляции, выполнив несколько простых операций.

7. Программист должен иметь возможность выпускать обновление для системы клиента, не зависимо от любого другого программиста независимо от того, в каком проекте (DLL) находится патч. Он должен быть способен сделать это быстро (менее 30 минут). Это делает концепцию единого официального выпуска практически невозможным.

8. Обмен кодом между разработчиком, работающим над тем же проектом, должен быть простым и быстрым.

9. Учитывая нашу огромную базу кода, мы хотим ограничить, насколько разработчик должен перекомпилировать, когда он получает патч (совместное использование двоичных файлов является обязательным).

10. Разработчик должен иметь возможность переключаться с одного системного релиза или ветви на один из них на другой (обычно приходится работать одновременно с несколькими релизами).

Edit: -Мы не использовать Makefile до сих пор, но это то, что мы готовы рассмотреть. Все построено с использованием VS-решений.

Answer 1

Git сам по себе отлично подходит для множества ветвей исходного кода. Тем не менее, обслуживание этих филиалов всегда будет находиться у пользователя и выходит за рамки данной системы управления версиями.

Единственная проблема с Git заключается в том, что она недостаточно масштабируется для отслеживания скомпилированных двоичных данных с течением времени. Двоичные данные в основном используются один раз, а атрибут diff/patch, который важен для исходного кода, не важен для скомпилированных двоичных данных. Вместо этого просто создайте ZIP-файл для каждой версии исходного кода в Git, содержащий предварительно скомпилированную версию каждой DLL и поместите эти .zip-файлы в общий сетевой ресурс.

Если вы это сделали, похоже, что вы должны инвестировать время в свою систему сборки, чтобы быть эффективными.Версия системы может помочь здесь, но вы, вероятно, работает с проблемами сборки в любом случае:

• Ваша система сборки должна только скомпилировать DLL, когда источник изменяется, или библиотеки DLL, от которых зависит уже его интерфейс изменился. Насколько сложно это зависит от используемого языка: DLL C# имеет довольно строгий интерфейс, который делает это довольно простым, в то время как C не имеет интерфейса, чтобы говорить (просто добавьте один #define в исходный файл, и все, возможно, придется скомпилировать)
• Ваша система сборки должна повторно использовать предварительно скомпилированные библиотеки DLL, которые должны храниться где-нибудь. Предпочтительно не так, как исходный код, поскольку Git не оптимизирован для этого.
• Ваша система сборки должна справиться с измененной веткой OK. Например, Visual Studio оставляет некоторые файлы позади и не всегда правильно определяет, когда нужно выполнить полную перестройку.
• Возможно, ваша система сборки должна будет использовать компилятор из фиксированного местоположения вместо установленного на вашем компьютере разработчиков ПК-компилятора. Возможно, вы захотите также установить его под контролем версий или, по крайней мере, сделать эту зависимость явной.

В конце концов мы свернули нашу собственную систему сборки, которая к тому времени была ограничена скоростью, чтобы сделать stat() всех файлов, когда ничего не изменилось. Однако для этого потребовалось некоторое время. Что нужно учитывать при построении собственной системы:

• Сначала постройте граф зависимостей: DLL зависит от исходных файлов и других DLL.
• Используйте время модификации (mtime) файлов как своего рода «версию» файла. Храните кеш в течение этих mtimes и рассматривайте изменение mtime по причине обновления вашего кеша.
• Когда одно mtime файла было изменено, вам необходимо перестроить DLL, к которой он принадлежит. После воссоздания DLL проверьте, изменился ли интерфейс. Если интерфейс изменился, перестройте все библиотеки DLL, которые зависят от этого. Это позволяет обход графика только для обработки DLL.
• Бонус для параллельного выполнения компиляции. Поскольку вы знаете свой график зависимостей, вы также знаете, какие библиотеки DLL можно строить параллельно.

И хорошо, что это вся система контроля версий независимо, поэтому она не пропадает времени. Возможно, даже простое приближение достаточно, чтобы это можно было сделать < 30 минут. Это зависит.