Comments 6
Вывод: автоматизация хорошо, но когда она одинаковая на уровне всех команд и проектов — ещё лучше. Буду признателен уважаемой публике за идеи, как красиво организовать переиспользование подобной конфигурации.
Легко! В последнем гитлаба появилась директива include.
Она позволяет набрать коллекцию шаблонов пайплайнов в отдельных yaml файлах, а потом подключать те, которые подходят под сборку конкретного проекта.
Больше не нужно бегать по десятках .gitlab-ci.yaml и вносить одни и те же коррективы
Ещё не понял два момента
- рецепты ansible. Окей. Админы не используют ansible, а вероятнее всего централизованную систему типа puppet/salt. Так они оба умеют в standalone конфигурацию. Т.е. чисто гипотетически можно натянуть сову на глобус и писать унифицированные "состояния" или "плейбуки", но это несомненно ещё один уровень сложности. Дополнительно докер, ну, никак не решает сам по себе проблему настройки окружения. Доставка кода — да. Окружение же нужно как-то сформировать. И здесь опять очень разумно взять готовый scm и написать нужные роли/состояния/манифесты.
- капистрано. Было бы круто давать ссылки на все используемые инструменты. Это раз. Два — почему capistrano/deployer, а не octopus deploy? Ну, это как пример. И три — эта вся история с деплоером только лишь потому что докер используется только для разработки/тестов? Было бы круто контейнеры тащить и в production. Никто не говорит, что это легко и просто, но это очень сильно унифицирует среду и позволяет по сути сделать единый относительно быстрый пайплайнов, не загаживая целевую машину ненужными зависимостями. А далее можно мигрировать и на кубернетес когда-нибудь )
Ещё очень интересно какая культура взаимодействия между отделами. Devops или не-Devops? Как распределяется ответственность между командами эксплуатации и разработки. Нет ли затыков при релизах в прод (это кто делает? Админ или всё-таки qa?)? И т.п.
1. Docker как раз обеспечивает всё необходимое для запуска приложения окружение. Или мы не поняли друг друга.
2. Про ссылки на инструменты согласен, хорошая идея. Capistrano — наследие, «живых» свидетелей принятия решения не осталось, искать ответ «почему» смысла не имеет.
Deployer — большая часть разработчиков владеет php, и значительная часть приложений содержит php. Это значит можно почти любому поручить поддержку/разработку CI/CD и достигнуть большего единообразия в используемых технологиях. Так проще и дешевле.
Если коротко: администрирование и разработка — отдельные отделы. Группа тестирования (она же QA) входит в отдел разработки. За эксплуатацию отвечают администраторы, за релиз в прод QA. Тема обширная, тут тянет на отдельную «ретроспективу изменений в процессах тестирования и эксплуатации»). Культура взаимодействия, это то что сейчас хочется улучшать, и публикация на подобную тему может стать хорошей совместной работой. Большое спасибо за идею!
PS: За последний год совсем кардинальных изменений не было, так что в целом ты ещё должен помнить что и как =)
2. Про ссылки на инструменты согласен, хорошая идея. Capistrano — наследие, «живых» свидетелей принятия решения не осталось, искать ответ «почему» смысла не имеет.
Deployer — большая часть разработчиков владеет php, и значительная часть приложений содержит php. Это значит можно почти любому поручить поддержку/разработку CI/CD и достигнуть большего единообразия в используемых технологиях. Так проще и дешевле.
Если коротко: администрирование и разработка — отдельные отделы. Группа тестирования (она же QA) входит в отдел разработки. За эксплуатацию отвечают администраторы, за релиз в прод QA. Тема обширная, тут тянет на отдельную «ретроспективу изменений в процессах тестирования и эксплуатации»). Культура взаимодействия, это то что сейчас хочется улучшать, и публикация на подобную тему может стать хорошей совместной работой. Большое спасибо за идею!
PS: За последний год совсем кардинальных изменений не было, так что в целом ты ещё должен помнить что и как =)
- несомненно обеспечивает. Но речь про другое. Условно — если разработка и тестирование в докере, а продакшн — не в докере, то докер решает только задачу ускорения разработки. В этом случае среда в production отличается от тестовой, т.к. те же пакеты, которые тянутся в Dockerfile и php-модули, нужно устанавливать на целевой сервер. И тут как раз начинается ад для ops'а.
Понятно, что blue/green выкатку можно сделать И БЕЗ Докера. Путем создания "нулевой" ВМ, накатки на нее всех конфигов и переключения трафика на новый инстанс. Но это куча ручной работы (которая, конечно же, автоматизируется в конечном счете). - Я сам capistrano потыкал. И мне этот утиль не очень понравился. Тем более, что требуется знание ruby. Парни говорят, что можно еще для тех же целей fabric использовать (python штука), но по мне — проще от всего этого отказаться и по максимуму писать в гитлабовском yaml'е всю логику. Опять же — в случае докера процесс раскатки может быть очень простой: docker pull обновленные образы, потом docker-compose up -d и полетели. Ну, надо еще про миграции не забыть и т.п.Я бы мог еще посоветовать https://octopus.com/pricing/overview, но он с какого-то момента стал, IMHO, сильно платный, без особых бенефитов.
Короче. Deployer — понял, унификация среды, чтобы стоимость поддержки разрабами (которые знают php) была не очень большой.
«ретроспективу изменений в процессах тестирования и эксплуатаци
ну, будем ждать ))))
.
Sign up to leave a comment.
Ретроспектива автоматизации и изменений в процессах разработки Timeweb