Питання
Чи є законна причина НЕ використовувати SVN для виробничих розгортань, або це лише випадок особистих уподобань і немає справжньої справи проти SVN?
Фон
На моєму робочому місці є культура тегів випуску в SVN, а потім їх розгортання безпосередньо на різних веб-серверах, використовуючи svn coабо svn switchвключаючи безпосередньо виробництво.
У мене особисто виникають проблеми з цим, оскільки я вважаю, що без використання сценарію збирання та розгортання або якоїсь форми або автоматизованого розгортання ви втрачаєте налаштування середовища інтеграції, оскільки вони недокументовані. Однак більш ніж у мене є відчуття кишки, що може бути прихована небезпека робити те, що було упущено, щось, що ще не повинно занепокоїти свою потворну голову.
Я висловив свою стурбованість операційним персоналом, який відповідає за розгортання коду в наших різних середовищах (постановка, попередній продаж, виробництво) і т. Д. Їх аргументи були в значній мірі тим, що він працював досить добре до цих пір, немає причин для змін.
Редагувати:
Що я маю на увазі щодо створення та розгортання:
Наприклад, якщо розробник вимагає додавання налаштування web.config для певного середовища. Web.config, як правило, не зберігається у svn, тому ці файли оновлюються вручну без будь-якої форми автоматизованого сценарію збирання. Тож якщо вони загублені або OPS забули додати поле до web.config для випуску, то у вас виникнуть проблеми.
Сценарій побудови, який каже, що використовує XMLPoke для автоматичного генерування web.config, відповідного для певного середовища, ідеально підходить тим, що у вас є надійний сценарій, який документує всі необхідні зміни для кожного вашого середовища.
Поточний метод збірки та розгортання
Для проекту, про який йдеться, розробник створює реліз вручну, інші проекти мають автоматизований крок збірки або з NANT, або з MSBuild, що в порядку.
Міграція баз даних для більшості проектів здійснюється через сценарії БД, або сценарії міграції (Migrator.NET), або пакети CMS.
CI, як правило, проводиться Team City на основі реєстрації, у нас є процес перегляду коду, що всі квитки робляться у відділеннях, а потім перевіряються на перевірку валідності та правильності / якості перед тим, як перевірити в багажник (працює добре).
Однак фактичне розгортання коду, як правило, завжди здійснюється через SVN, або через замовлення тегованого випуску, або, загалом, SVN Switch. Це щось незручне для мене, що ми використовуємо наше сховище як частину процесу розгортання.
Конфігурація, як правило, не змінюється дуже часто, єдині речі, які будуть міститись у конфігураційних файлах, - це інформація, що стосується середовища. Все інше знаходиться в db.
Не зрозумійте мене неправильно, це працює, це працює добре. Однак я хочу спробувати надати автоматичну збірку та розгортання. Я використовував це для Rails і Capistrano, і для особистих проектів, використовуючи Cygwin, Nant та SSH.
Що ще важливіше, мені знадобляться дуже конкретні вагомі аргументи, щоб змусити колег перейти на використання автоматизованої збірки та розгортання.
Або НЕ існує реальних вагомих аргументів проти використання SVN спеціально для розгортання у виробництво?