в этом смысле "работает - не трогай" это плохое правило, потому что оно превращает каждый деплой в аварийную и исключительную ситуацию

если с такой стороны посмотреть - то да

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

работает - повтори и не трогай

а сам ssh может быть вреден, точнее не сам ssh, а например sftp - нарывался на ситуации, когда канал забит в полочку - sftp просто перестает работать

работает - повтори и не трогай

ну если так разве что

а сам ssh может быть вреден, точнее не сам ssh, а например sftp - нарывался на ситуации, когда канал забит в полочку - sftp просто перестает работать

ну ssh вреден в том смысле, что мало ли что там поменяли на сервере и никто не знает теперь, что происходит

это да

никаких ssh на сервер! :))

так что blue/green и вперед

угу - самое верное

во

blue\green это из какой оперы?

хорошо что вы сказали про проблемы деплоя по ssh.

https://habrahabr.ru/post/309832/

шикарно! Спасибо

А что там на картинке? 2 разные базы?

у меня только всегда остается открытым вопрос базы данных. Как можно тестировать приложение на живых данных и при этом не на живой базе? Копировать базу каждый раз может быть сложно из-за ее размера...

Ну и соответственно у продакшена одна база

у меня только всегда остается открытым вопрос базы данных. Как можно тестировать приложение на живых данных и при этом не на живой базе? Копировать базу каждый раз может быть сложно из-за ее размера...

у всех это вопрос :))

изменения не всегда только со стороны кодовой базы, но и структуры БД

С базой начинаются пляски, да ) Сложная тема

ну, а как решать-то?

ну как - никак

есть какой-то красный\коричневый вариант для базы?

зависит от приложенния

ну, а как решать-то?

Миграциями обратно-совместимыми

ну тестами и стейджингом

частично миграции помогают

но частично

ну тестами и стейджингом

вот у меня выше вопрос - как тестить на живых данных но не на живой базе?

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

вот у меня выше вопрос - как тестить на живых данных но не на живой базе?

создавать копию бд для стейджинга

самый простой вариант это делать еженедельно копию БД продакшена и там тестировать.

а что ты имеешь ввиду под тестовым приложением и как ты хочешь его тестировать?

да, примерно ясно :)

а что ты имеешь ввиду под тестовым приложением и как ты хочешь его тестировать?

мне вопрос?

ага

ага

ну смотри. Есть код приложения и у него есть два состояние дев и прод. Отличаются они конфигами. Я пока сталкиваюсь с тем, что для теста приложение надо немного подшаманить: сменить конфиги БД, добавить настроек и входных скриптов... и кароче получается что тестируем приложение с одними конфигами, а на прод уходят другие - не дело это. Хочется запаковать код в контейнер и больше в нем для теста ничего не менять, а, например, линковать к контейнеру с кодом контейнер с тестовой базой (копию прода) и там тестить. Ну а как тестить... автотестами :)

а мб просто тесты писать интеграционные? Проблему нашел - понял - написал интеграционный тест - он свалился - пофиксил проблему - фикс ушел в прод

если говорить о ручном тестировании, то скорее всего живые данные в большом объеме не нужны. А все остальные можно залить самостоятельно. У нас вот, например, есть специальная миграция с тестовыми данными

а мб просто тесты писать интеграционные? Проблему нашел - понял - написал интеграционный тест - он свалился - пофиксил проблему - фикс ушел в прод

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

а мб просто тесты писать интеграционные? Проблему нашел - понял - написал интеграционный тест - он свалился - пофиксил проблему - фикс ушел в прод

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

если раз в год, то допустимо :)

если каждый деплой, то ппц

если каждый деплой, то ппц

это диагноз тогда уже :)

гитХАБ деплоит код на продакшен по 20 раз в день

на хабре статья была. СмеЛЫЕ ребята. Видать у них все на столько отлажено что можно деплоить в полном автомате.

> Смешые ребята. > Смешные

гитХАБ деплоит код на продакшен по 20 раз в день

не показатель - там же тоже куча сервисов

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

Смелые**

они не смелые, они умные

20 раз в день хуйня

есть люди, которые сотни раз в день деплоятся

амазон например

ну код заливать не проблема, тесты пиши и все.

по факту, если ты большой продуктовый бизнос с веб-приложением — это обязательное условие выживания

в 2017

а вот когда чет с базой меняется, я хз как так делать чтобы все на автомате.

иконку перед монитором поставить и пальцы крестить качественно :)

есть люди, которые сотни раз в день деплоятся

Ты имеешь в виду людей которые прямо на продакшене пишут код?

Ты имеешь в виду людей которые прямо на продакшене пишут код?

нет.

хаха

Ты имеешь в виду людей которые прямо на продакшене пишут код?

естественно

у меня CI на каждый коммит работает ~10 мин. Мне не с чем сравнить, так как первый мой CI сценарий. Но это моного или нормально? 1. Сборка кода 2. Сборка контейнеров 3. Релизит контейнеры после теста 4. Выкладывает на прод

лучше напиши тайминги каждой фазы

ERROR: S client not available

если у тебя сборка занимает 8 минут, то хуле тут делать

а вообще 10 минут это довольно много, как по мне

Это как-то многовато оверхеда, на каждый комит пересобирать все.

Ты каждый комит чтоли деплоишь на прод?

пока что да :) Но планирую разбить по веткам чтобы только деплой на прод столько занимал

Compile: 1 minute 13 seconds Build: 3 minutes 29 seconds Release: 1 minute 10 seconds Deploy: 1 minute 44 seconds

а тесты?? :))

их пока что нет, так что и запускать нечего:)

И что значит фаза Release ?

контейнеры тестовые метятся тегами релиза и пушатся в регистри

типа nginx_latest_test => nginx_latest

засирается регистри контейнерами сильно, но пока другого не придумал.

ммм, build это билд контейнера?

чот долго

оно там все зависимости ставит штоле?

да, там собирается два конетйнера. И да, там зависимости проекта ставятся.

вот тут можно же пооптимизировать

у тебя зависимости часто меняются?

сделай, например, base image с уже установленными зависимостями

и зашедуль его сборку раз в сутки ночью

а все контейнеры собирай унаследованными от этого имиджа

выиграешь много времени на сборке

Спасибо, отличный вариант!

более того, там все сведется к ADD app/

А как бы сделать так, чтобы не засирать регистри контейнерами с метками?

гарбедж коллектор в регистри настроить

а такое в gitlab registry есть? я не находил :(

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

Да, нашел какие-то заметки в гугле. Почитаю, спасибо!

А/б тестирование не?

Ну и потом не удивляйтесь ах у нас данные клиентов утекли лол

А/б тестирование не?

а/б тестирование чего?