Как правильно организовать инфраструктуру продакшена и процессы разработки, тестирования и деплоя?

Question

[O Di]

Предположим, что мы с вами - некая IT компания, которая для создания своих веб-продуктов нанимает разработчиков, пусть это будут Ruby-разработчики (мы не держим их в штате). У нашей компании есть собственные серверные мощности, которые можно задействовать (под хостинг, тестирование и т.д.).
В качестве отправной точки будем использовать поднятый нашими админами локальный git-сервер (например GitLab), так как разрабатываемые нами проекты - закрыты (нанятые разработчики ставят подписку о неразглашении), и bug-трэкер (например Redmine).
С этого момента необходимо продолжить организацию инфраструктуры и процессов (разработка, коммиты, тестирование, приемка, деплой), удобных как для разработчиков, так и для нас.

Answer 1

[Константин]

Так, система управлениями версиями у вас есть, теперь посмотрите на автотесты, юнит тесты, прочие системы автоматизированного тестирования, затем на системы хранения версий\отдельных библиотек , затем на системы управления серверами и ПО на них, системы мониторинга, а так же та то, как это всё связать, дополнительно можно посмотреть в сторону devOps

Если рассматривать сферического коня в вакууме, то примерно так:
разработчик делает коммит в git -> git c помощью хуков проверяет синтаксис ( если это код), еще что-либо, если все окей, то коммит проходит -> некая система типа jenkins\bamboo\etc видит новый коммит, разворачивает новый поделку, затем прогоняет юнит\смоук\прочие автотесты -> если тесты не прошли, то создаёт тикет в баг трекере , если тесты прошли - проставляет метку\версию , возможно заливает результат в некий репозиторий, либо в какую-нибудь хранилку ( типа artifactory ) -> система управления серверами ( либо в ручном режиме админ ) обновляет сервера -> по окончанию - неплохо бы проверить, что покажет мониторинг и отправить письмо радости менеджеру проекта.

Как-то так, но опять же , это конь в вакууме в идеальном мире. А еще можно книжки разные почитать =)

UPD: а еще вот хороший статья - habrahabr.ru/post/197026

Comments

[Константин]

Про инфраструктуру серверов ничего не скажу, всё зависит от нужного аптайма, требований к отказоустойчивости и наличия $$

[Saboteur]

> разработчик делает коммит в git -> git

Обычно разработчик делает коммит в систему code review, например Gerrit
Тут или сразу срабатывает тот же jenkins и делает тестовый билд, чтобы проверить что проект собирается, можно и автоматические тесты замутить.
А уже другие разработчики или интегратор, аппрувит этот чендж и он мержится в основную ветку.

[Константин]

Сергей: про gerrit не скажу , т.к. "обычно" у всех по разному, про jenkins - вы продублировали то , что я написал, про аппрув ченджа - это всё можно автоматизировать, мы же говорим об абстрактном коне в вакууме ? )

[O Di]

TheSpbra1n: благодарю! :)

Answer 2

[Saboteur]

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

Можно настраивать CI, можно разводить agile процессы, но главное - выяснить требования заказчика, и подстраиваться под них.

Comments

[O Di]

А если предположить, что мы (вы и я) - и есть компания-заказчик, и нам необходимо наладить все эти процессы? :)

[Saboteur]

O Di: Так сами требования хотя бы напишите, и уже под них подстраивайтесь. То, что вы компания заказчик поможет в случае чего поменять требования, чтобы проще было жить. Но только вы знаете, что именно вы хотите.
Вам нужно каждый день выпускать новую версию? Каждые полгода? У вас 100 разработчиков поделенных на разные проекты или 10 разработчиков в одной команде? У вас требования к безопасности на уровне подписки о неразглашении, или опенсорс?

Тот же деплой не очень ясно как он должен происходить - вебсайт на внешний хостинг? мобильное приложение на бета-железку, которой еще нет в продаже? Коробочный продукт под какую-то конкретную операционку?

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

[ТыжСисАдмин]

Сергей: но это уже лучше нежели предыдущий вопрос :)

[O Di]

Алексей POS_troi: да, но и внимания к вопросу на порядок ниже )

[ТыжСисАдмин]

Там было не внимание а холивар :)