Использовать SVN/GIT для истории версий программного обеспечения? Или что-то другое?

Question

В настоящее время я работаю над реализацией инфраструктуры управления версиями для наших корпоративных приложений. Вы знаете, V1.1, 1.2 и т.д. Для наших приложений.

То, что я хотел бы сделать, это иметь простую настройку записи изменений программного обеспечения и истории версий. Мы уже используем SVN (и переходим к GIT), и часть меня просто говорит, что используйте это. Но другая часть не дает мне покоя, говоря, что этого недостаточно.

Бизнес на самом деле не хочет проходить траление нашего репозитория SVN, не так ли? Мне было интересно, если кто-то знал о лучшем способе сделать это? Какие-либо предложения?

Спасибо Стив

Answer 1

По моему опыту, сообщения о коммитах обычно содержат технически подробные сведения о внесенных изменениях. Обычно они не подходят для заметок о выпуске. Для этого я держу более дружественный документ с заметками о выпуске. Я надеюсь перейти к веб-системе, такой как Redmine, которая может отслеживать улучшения и ошибки.

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

svn log --verbose https://<address to server>/<repo name>/ > svnMessages.txt

Answer 2

Я использую журнал изменений, чтобы сообщить об ошибках, изменениях или новых функциях конечным пользователям. Я моделирую свой журнал изменений на tortoisesvn, который использует BUG: CHG: NEW:.

Я помещаю строки журнала изменений в историю хранилища с помощью коммитов вместе с более технической информацией, которая входит в коммиты. Это объединяет две задачи во времени, регистрируя технические изменения, а также то, что должно быть видно на более высоком уровне для пользователей.

Когда я освобождаюсь, я могу легко вытащить все последние строки журнала изменений и обновить журнал изменений / веб-сайт / и т.д. С помощью префиксов в любой строке журнала изменений в истории коммитов я также могу автоматизировать это.

Мне нравится, как этот метод объединяет два потока информации в хранилище, где они должны быть.

Answer 3

Вы можете использовать git у себя дома, а затем просто делать вырезки из репозитория для основных версий (тарболы).

Answer 4

Я бы выбрал систему контроля версий, которую предпочитает ваша команда разработчиков (склоняясь к git, если они апатичны!). То, что вы хотите, - это стандартный метод «публикации» основной версии вместе с журналом изменений. Это можно сделать с помощью скрипта, который загружает из репозитория и отображает журнал изменений, через веб-систему, это может быть просто общий каталог в локальной сети, FTP-сайт и т.д. И т.д. И т.д.

Answer 5

Ваш вопрос:

Бизнес на самом деле не хочет проходить траление нашего репозитория SVN, не так ли? Мне было интересно, если кто-то знал о лучшем способе сделать это? Какие-либо предложения?

Дополнительная информация, которую вы предоставили:

Не-разработчик, может быть, член Business из-за пределов IT, хотел бы знать об изменениях, которые произошли в последнем выпуске, исправлениях ошибок и т.д. Поэтому вы не хотите хранить там историю версий для всего бизнеса, но, возможно, в отдельном месте. система

Отдельная система: Microsoft Exchange

Решение: напишите им, когда выйдет новый релиз.

Answer 6

У всех проектов, над которыми я работаю, есть вики для разработчиков и пользователей. Вики в основном используется для документации / помощи, но также включает в себя журналы изменений, подходящие для конечных пользователей. Журнал изменений обновляется ежедневно, обращаясь к управлению версиями, если требуется, с окончательным редактированием и полировкой после выпуска сборки.

Многие пользователи, особенно плательщик счетов при удаленной работе, ценят ежедневные обновления.