Контроль версий и управление релизами

Question

Существуют ли так называемые "системы контроля версий", которые также поддерживают фактическое управление выпуском / развертыванием?

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

Насколько я понимаю, «более современные» инструменты контроля версий поддерживают только часть управления исходным кодом. Это понимание правильно?

Answer 1

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

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

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

[EDIT] Добавленная стоимость CI-сервера:

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

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

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

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

Answer 2

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

В Subversion мы используем хук post-commit для развертывания копии приложения на сервере разработчика каждый раз, когда разработчик проверяет код.

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

Answer 3

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

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

Answer 4

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

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

в вопросе, и из-за того, что вопрос помечен version-control ...

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

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

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

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

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

Answer 5

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

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

Answer 6

В мире ruby ​​on rails Capistrano - лучший инструмент для развертывания.

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

Answer 7

-> Насколько я понимаю, «более современные» инструменты контроля версий поддерживают только часть управления исходным кодом. Это понимание правильно?

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

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

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

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

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

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

надеюсь, это поможет

Answer 8

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

Некоторые поставщики поставляют комплексные инструменты под заголовком Управление жизненным циклом приложений