Управление версиями: лучший инструмент для запасных программных файлов, часто выпускаемых отдельно - PullRequest
0 голосов
/ 23 ноября 2010

Доброе утро, ребята.На этот раз общий вопрос об инструментах управления версиями.В моем доме 15 человек работают на ACU COBOL, производя программное обеспечение для управления аптекой.Я единственный .NET парень, работающий над другим интеграционным SW.Этот пакет управления состоит из 300-400 программ, и мой коллега часто модифицирует и выпускает программы в виде запасных zip-пакетов;философия аналогична «скользящему выпуску» в дистрибутиве Linux.

Какой инструмент версионности может быть лучшим в такой рабочей среде?Теперь они не используют какой-либо инструмент управления версиями, поэтому у них нет предвзятых мнений: просто новая вещь для изучения и использования.Они должны отслеживать изменения в программах, используя сортировку тегов, поэтому, когда им нужно опубликовать исправление (zip-пакет), они могут зайти в репозиторий и получить помеченные измененные программы для выполнения определенного запроса.Мы думаем о Mercurial и Trac, но я хотел бы узнать от других разработчиков, есть ли лучшие инструменты для управления нашей конкретной работой и выпуском релизов.

Спасибо!
Nando


Спасибо, VonC!Я постараюсь лучше объяснить наши потребности.

Что ж, история отслеживания важна для нас, поэтому VCS (DVCS, как Mercurial) может быть хорошим выбором.

Теперь управление источниками завершеновручную: есть папка, которую мы используем как основной ствол, и где разработчик делает свою работу.Работая над устранением ошибки или осуществляя новые «срочные» запросы функций (мы работаем с аптеками, на которые влияют тысячи различных законов, которые мы не можем игнорировать…), они записывают в таблицу Excel (!), Какие программы влияют на их работу;по завершении они компилируют эти программы в режиме выпуска, собирают zip-файлы, а затем публикуют его в нашем пользовательском веб-приложении, где наш дистрибьютор sw может получить его и опубликовать на своем пользовательском веб-интерфейсе, где находятся их клиенты (используя наш sw для управления).можно получить обновления.

Нам необходимо отслеживать этот метод работы:

Ошибка срочной функции для реализации -> создание Ticket (выпускать, отслеживать, называть так, как вы хотите, но комментарий, где регистрировать работу, выполненную на естественном языке, а справочная служба, а не разработчик, может понять проделанную работу) -> work & debug -> тег (например, «fix-123») программы, затронутые этим тикетом -> коммит в основной ствол -> получают только модифицированные программы, поиск по тегу «fix-123» -> компилировать только эти программы -> собрать zip и выпустить (по-нашему, это не важно).

Mercurial может быть решением,но я только хочу знать, были ли у кого-то еще такие же проблемы и как их решали.

Спасибо!
Нандо

1 Ответ

0 голосов
/ 23 ноября 2010

Я бы посоветовал дифференцировать:

  • управление источниками (управляется в репозитории VCS, центральном с Subversion или децентрализованном с Mercurial или Git: см. различия между DVCS и CVCS ). В этом ответе SO .
  • управление выпуском (с бинарными артефактами, такими как ваши почтовые индексы, лучше управляемыми в более общем хранилище, таком как maven с Nexus).
    Тот факт, что вы освобождаете, часто означает, что вам придется «очистить» какой-то старый выпуск, который вам больше не нужен (и который есть, выпуск за выпуском, ваше дисковое пространство, а также ваши резервные копии): гораздо легче удалить старый артефакт в репозитории Maven (например), чем в любом инструменте VCS (которые предназначены до сохраняют историю!)
...