Деплоить в production из VCS (система управления версий) это нормальная практика?

Question

[Dmitry Shnyrev]

Хочу услышать мнение опытных специалистов по такому вопросу
"Деплоить в production из VCS (система управления версий) это нормальная практика?"
Почему возник вопрос. В интернете куча примеров как можно организовать деплой в продакшен. И все эти примеры разделяются на 2 основных направления:
1. деплой через VCS - т.е. заливаем в репозиторий, на проде сливаем из репозитория.
2. деплой из dev (uat) сервера по SSH используя различные утилит автоматизации. Т.е. в этом случае прод ничего не знает про какие-либо репозитории.
Я как бы склоняюсь к первому варианту (через VCS) - он очень удобный (уже использовал). Но если ли какие-нибудь проблемы (минусы) данного способа? Может какие нибудь проблемы безопасности?

Answer 1

[Andrey K]

Самый лучший вариант деплоить из Continuous Integration сервера. Но, за неимением такового, чаще всего деплоят из VCS, основная проблема безопасности это хранение конфигов и ключей в VCS.

Comments

[Dmitry Shnyrev]

С ключами понятно. Файл config в gitignore например и потом отдельно ручками на прод.
Что можно посмотреть по поводу Continuous Integration серверов? Никогда не сталкивался.

[Andrey K]

habrahabr.ru/post/190412
habrahabr.ru/post/82724

[Dmitry Shnyrev]

Я по поводу безопасности почему спросил. Не особо глубоко разбираюсь в том же Git который использую. Но вот к примеру ситуация - злоумышленник попадает на сервер (ладно серверу и данным хана). Но сервер также подключен к системе контроля версий и следовательно злоумышленник получает доступ и к основному VCS репозиторию. Что теоретически он может там натворить? Есть ли возможность как то ограничить доступ к репозиторию со стороны сервера на запись в этом случае?

[Dmitry Shnyrev]

Andrey: за ссылки спасибо :) изучу.

[Andrey K]

Для таких случаев серверу дается доступ к репозиторию только на чтение (Делается это в разделе deployment keys в github и bitbucket).

[Dmitry Shnyrev]

Andrey: Спасибо за еще один полезный совет :)

[Dmitry Shnyrev]

Andrey: На какое CI посоветуешь обратить внимание? Смотрю что решений популярных много и в тех же комментах на Хабре настоящий коливар по этому вопросу. На слуху Jenkins и Bamboo (оказывается слышал про них не раз, но так и не удосужился разобраться для чего они).

[Andrey K]

Jenkins, TeamCity

[Don Kaban]

Я бы тоже советовал TeamCity

Answer 2

[vsuhachev]

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

Касательно рельс при использовании VCS деплоя сталкивался со следующими проблемами:

1) в VCS может хранится куча информации (тесты, тестовые данные, документация, файлы для разных платформ и т.д.) которая для конкретной инсталляции не нужна и замедляет установку.

2) сборка ассетов (coffescript, sass) происходит на удаленной машине и опять замедляет установку.

Answer 3

[Андрей Гриневич]

К сожалению не дам конкретного ответа на ваш вопрос, но лишь посоветую глянуть в эту сторону.

Comments

[Dmitry Shnyrev]

Это плохая сторона для продакшена. Нельзя синхронизировать прод с чем либо таким образом. rsync мгновенно синхронизирует папки на двух разных машинах (зеркалирование ). Деплой на прод должен осуществляться "вручную" когда это надо. То что вы посоветовали больше подходит для синхронизиции dev сервера и машины разработчика, когда надо чтобы любой "чих" сразу попадал на сервер для тестирования.

[Андрей Гриневич]

Dmitry Shnyrev: хм, почему нет? Добавить файлы для игнорирования, скрипт с ручным запуском и код быстро перемещается куда нужно

[Dmitry Shnyrev]

В прицепе, если сделать отдельную папку и связать ее с продом, то в этом есть смысл. Просто переносить в эту папку код из рабочей папки по необходимости тем же скриптом. Тогда, да, согласен можно такое сделать, тогда отпадет необходимость лазить на прод по ssh. Но это тогда получается 3 способ в дополнение к первым двум что я указал.
А синхронизировать рабочую папку проекта на dev или тестовом сервере с продом надеюсь никто не догадается :)