Управление версиями и выпусками

контроль версий имеет мало общего с управлением выпуском или развертыванием, поэтому имеет смысл, что VCSs не пытаются сделать это.

то, что я видел в этой области, - это build или серверы непрерывной интеграции (CI). Они слушают изменения в VCS, делают новую проверку на любой фиксации, а затем пытаются построить все. Таким образом, они интегрируют VCS и инструменты сборки, собирают журналы из них и представляют все в хорошем веб-интерфейсе.

этот таким образом, каждый инструмент может оставаться простым.

[EDIT] добавленное значение сервера CI:

1. Он может анализировать выходные данные ваших сценариев сборки и представлять обзор в Почте или веб-странице.

2. Он гарантирует, что все тесты выполняются после фиксации. Нет больше ", но это работает для меня".

3. некоторые из них поддерживают отложенную фиксацию (она будет фиксировать изменения только в VCS, когда все тесты run)

4. Он может запускать сборки на нескольких проектах, которые зависят друг от друга.

Это зависит от того, сколько денег и времени вы хотите инвестировать в такие системы. многие люди используют простой контроль версий, например svn, и управляют выпусками вручную (используя метки и ветви) Есть и другие (бесплатные) инструменты для непрерывной интеграции (постоянное построение приложения), такие как cruisecontrol.

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

Я думаю, что то, что вы называете release management здесь чаще называют автоматизация сборки. В этом пространстве есть различные инструменты (make, ant, Nant и т. д.), Но они, как правило, существуют как отдельные инструменты. Часто можно вытащить код из отдельного управления версиями, и вы получите продукты, предназначенные для наблюдения за процессом (который называется непрерывной интеграцией, когда это делается автоматически.)

есть некоторые поставщики, которые отправляют сквозные инструменты, которые идут под заголовком Управление Жизненным Циклом Приложений

--> Я понимаю,что" более современные " инструменты управления версиями поддерживают только часть управления версиями. Правильно ли это понимание ?

VCS просто имеет дело с частью управления версиями, и это бессмысленно, если вы не можете получать уведомления об изменениях (и после того, как кто-то реализовал основы vcs, не будет никаких трудностей, чтобы обеспечить это; -))

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

Это называется автоматизацией сборки, и да, очень желательно, чтобы лучшие биты проекта были "готовы к отправке", когда кто-то вносит изменения, но не обязательно. Вы можете делайте все, что хотите, с инструментами, упомянутыми ранее (они расширяемы).

в непрерывная практика интеграции-это интерполяция этих точек на пути таким образом, у вас есть только чистый, стабильный и благородный код в репозиториях. Существуют так называемые серверы CI, которые соединяют части VC и BA.

проверьте эту страницу на CI http://martinfowler.com/articles/continuousIntegration.html

и если кому-то нужен сервер CI, совместимый со многими инструментами BA и многими VCS взгляните на JetBrains TeamCity

Надежда это помогает

в мире ruby on rails Capistrano является инструментом развертывания по выбору.

http://www.capify.org/index.php/Capistrano

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

пожалуйста http://www.ngashint.com для сайта блога проекта. Вы можете оставить свой адрес электронной почты, чтобы начать получать бета-версию или напишите Мне kzt001[at]gmail.com

этот вопрос привлек мое внимание, из-за

'... так называемые "системы контроля версий" ...'

в вопросе, и из-за вопроса, помеченного системы управления версиями ...

Я прихожу из мира мэйнфреймов (тоже), и мэйнфрейм " SCM " (=Управление изменениями программного обеспечения) - это все, что мы делали в течение последних 25 лет или около того.

Я немного удивлен (может быть "в шоке"?) чтобы увидеть все так называемые синонимы системы управления версиями тег. Особенно scm tag (и я не уверен, что процесс SE должен предложить, чтобы больше не рассматривать его как синоним). SCM, по крайней мере, в мире мэйнфреймов, намного больше, чем просто контроль версий (это всего лишь часть SCM). Как насчет любой из этих как-то связанных тем (которые, IMHO, подфункции SCM):

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

чтобы проиллюстрировать, насколько важны все они, я часто задаю этот вопрос, чтобы подумать: "что нужно сделать, чтобы применить (ошибку?)- исправлено программное обеспечение автоматического пилота в самолете ... Во время полета!?!? Другими словами: "каковы все шаги и процедуры, которые должны быть на месте, прежде чем вы почувствуете себя комфортно для такого исправления во время полета, на котором вы находитесь?".

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