TeamCity & deploy.

[Kirill Sukhonosenko]

Коллеги привет!

Надеюсь вопрос в тему рассылки.

У нас небольшая команда программистов - 10 чел - и все знаю что происходит в проекте (есть ревью и тп)

Мы используем три типа нод - балансер, апп-сервера, базы. Все на windows.

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

Системный софт накатываем политиками.

В идеале - и я надеюсь опытные коллеги меня поправят - я хочу получить такую схему:

- выкатка на бой, после того как пройдены защитные меры - авто-тесты + ручная проверка

- настройка выкатки делается программистом - он знает в каком окружении все у него работает (подключает 3rd party либы, пишет апгрейд скрипты БД, конфигурирует сервисы)

- в идеале он все это делает в своей IDE - Visual studio

- комит в ветку-ревью-пуш-автотесты на тимсити-выкатка на ручное тестирование.

- ок от ручного тестирования-деплой на бой.

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

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

Но при этом я хочу:

- видеть кто и что менял в конфигурации (git)

- чтобы конфигурации однотипных нод были одинаковыми (на тесте стейде и бою) - и это гарантировалось тулами

- деплой на боевой должен делаться по команде человека

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

Собственно вопросы:

- правильного ли я хочу? :) 

- позитивный или негативный опыт использования team city для этого - у нее заявлен деплой

- позитивный-негативный опыт использования связки team city + <cms> 

Спасибо! 

Кирилл

[Alik Kurdyukov]

Привет!

Ты примерно описал мою схему, только у меня не teamcity, а bamboo, но суть это не меняет. И то, что ты пытаешься сделать обычно называют continuous deployment.

У меня это сделано так

1. Репа состояний salt отделена от репы продукта - чтобы не развалить ее случайно

2. При исполнении задачи, которая требует изменения тестовой и/или боевой среды, в задаче это явно указывается и делается 2 pull req - на систему и на конфиги

3. (в процессе реализации) Накат происходит на тест по команде на успешном билде (для этого у bamboo есть т.н. manual stages), на бою - аналогично. Выкатка боя и теста происходит из разных веток git-а.

Собсно, для адекватной реализации этого я неспешно делаею bamboo task, которые будет уметь работать с salt master.

Пока в схеме проблем не вижу и потихоньку автоматизирую это дело.

Удачи!

Алик.

[Kirill Sukhonosenko]

Меня смущает в твоей схеме что есть две репы ) 

Девелопер написал одно, в деплой конфиурация другая - в итге факап.

А почему ты выкатываешь на тест и бой из разных веток?

Я хочу чтоб среда и все что выкатывается было одинаковым.

Я хочу 100% совпадения теста и боя

[Alik Kurdyukov]

Привет!

On 28 Apr 2014 at 12:01:32, Kirill Sukhonosenko (ksukho...@gmail.com) wrote:

Меня смущает в твоей схеме что есть две репы ) 

Девелопер написал одно, в деплой конфиурация другая - в итге факап.

Если не страшно, что девелопер что-то экзотично развалит - можно и объединить.

А почему ты выкатываешь на тест и бой из разных веток?

Потому что gitflow - есть ветка релиза и ветка девелопа. Когда на тесте девелоп похож на человека - его назначают релизом.

Я хочу чтоб среда и все что выкатывается было одинаковым.

Я хочу 100% совпадения теста и боя

Всегда завидовал людям, которые себе могут позволить 100% совпадения боя и теста :)

-- 
Best regards,

Alik Kurdyukov

[Kirill Sukhonosenko]

Совпадают по конфигурации а не по колву оборудования )
Gitflow мы тоже используем но по другому - мы тестируем ветку релиз тоже и выкатываем на бой из нее - и пожтому я стремлюсь бой и тест сделать одинаковыми - у нас были расхождения и ошибки изза этого

А почему разработчик должен накосячить что то в конфигурации?
Я исхожу из того что та часть разработки кто отвечает за внешние компоненты ничуть не глупее админов
И они собственно вполне могут и должны решать в каком окружении будет работать программа

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

Ну или хотя бы в одной

Ну ок - в общем понятно - спасибо )

[Oleg Soroka]

Вот эту книжку советую http://www.ozon.ru/context/detail/id/7243884/

А лучше - в оригинале

[Ilya Zharskiy]

вторник, 29 апреля 2014 г., 15:15:21 UTC+4 пользователь Alik Kurdyukov написал:

Всегда завидовал людям, которые себе могут позволить 100% совпадения боя и теста :)

Просто делайте тест (и дев)  снятием образов с production. Как только автоматизируете это - количество гимора уменьшится в разы.