Comments 13
А сколько команд из общего числа не использует построенный конвейер? Наверняка есть такие, кто не хочет (или это обязательное требование?) или не может. Какой-нибудь rocket-science на уникальных технологиях, к которому сложно прикрутить CI/CD. С продуктами SAS, в свое время, намучались и решили лучше не трогать, себе дороже делать CI оказалось.
Ну и мини-вопрос, какую технологию контейнеризации рассматриваете сейчас для внедрения?
Ну и мини-вопрос, какую технологию контейнеризации рассматриваете сейчас для внедрения?
Сейчас у нас примерно 90 % команд использует конвейер, для всех новых команд использование конвейера является требованием. Из оставшихся 10% часть команд это приложения под IOS +Android, для них мы сейчас создаем агенты, чтобы и их перевести на конвейер. Еще часть это команды в процессе перехода и совсем малая часть это приложения для которых использовать конвейер признали не целесообразным.
С SAS мы тоже помучились, но в итоге команде удалось реализовать и сборку и автодеплой через конвейер.
Технологии контейнеризации мы сейчас рассматриваем все основные, но пока ничего определенного сказать не могу. Процесс выбора только начался.
С SAS мы тоже помучились, но в итоге команде удалось реализовать и сборку и автодеплой через конвейер.
Технологии контейнеризации мы сейчас рассматриваем все основные, но пока ничего определенного сказать не могу. Процесс выбора только начался.
Интересно читать про изменения в крупных компаниях, а тем более — в банках.
Ответы на последние 7 вопросов не несут никакого смысла. Мне кажется, можно было вообще их не писать и закончить — coming soon.
Вы писали, что у вас было 120 компонентов для установки на агенты. Почему не использовать докер для победы над этой болью?
Ответы на последние 7 вопросов не несут никакого смысла. Мне кажется, можно было вообще их не писать и закончить — coming soon.
Вы писали, что у вас было 120 компонентов для установки на агенты. Почему не использовать докер для победы над этой болью?
По сонару подскажите — какая версия и сколько примерно времени проходит с момента запуска агента до записи в бамбу/ббэкет
Версия SonarQube у нас 6.7. Время напрямую зависит от сборки, и может исчисляться часами. В ближайшей перспективе разделение сборочных планов на два:
но тут тоже есть нюансы и есть над чем подумать.
- для проведения анализа
- для сборки артефактов
но тут тоже есть нюансы и есть над чем подумать.
Спасибо!
А SQ платный? Просто они и брэнчи и инкрементный анализ и геренацию репорта в агенте выпиливают из не EE :( И в итоге если не платить, то это такой тупичек для CI
А SQ платный? Просто они и брэнчи и инкрементный анализ и геренацию репорта в агенте выпиливают из не EE :( И в итоге если не платить, то это такой тупичек для CI
1. Когда речь заходит про автоматизацию развертывания, всегда очень интересно — а как автоматизируется интеграционное и приемочное тестирование API на тех средах, с которыми уже интегрируются внешние системы?
Например, если речь про эквайринг (не знаю касается статья этой части ваших систем), как проверяется полный цикл корректной работы как бы «извне», с точки зрения внешней системы?
Уточню что считаю это важным пунктом CI/CD, без автоматизации тестирования сильно падает темп выкатывания обновлений, либо же снижается надежность/стабильность.
2. Chatops — можете рассказать пожалуйста — увидели в этом потребность или просто экспериментируете на модной волне? Если держать общий чат для уведомлений о выкатывании — с наращиваем количества сервисов начнется жуткий спам, на мой взгляд.
Например, если речь про эквайринг (не знаю касается статья этой части ваших систем), как проверяется полный цикл корректной работы как бы «извне», с точки зрения внешней системы?
Уточню что считаю это важным пунктом CI/CD, без автоматизации тестирования сильно падает темп выкатывания обновлений, либо же снижается надежность/стабильность.
2. Chatops — можете рассказать пожалуйста — увидели в этом потребность или просто экспериментируете на модной волне? Если держать общий чат для уведомлений о выкатывании — с наращиваем количества сервисов начнется жуткий спам, на мой взгляд.
По первому вопросу к сожалению ничего не могу сказать т.к. наша команда занимается поддержкой и развитием самого конвейера, а ваш вопрос больше относится к продуктовым командам.
Зато про ChatOps могу сказать. Все началось как обычно на энтузиазме и постепенно вышло на уровень всего IT. В списке задач для СhatOps не только нотификации, но и такие вещи как получение списка задач из Jira, управление серверам (стоп/старт/рестар/постановка на обслуживание), управление релизами, создание аварийных чатов и т.д.
Часть этих задач уже пилотируется, но пока еще выбираем инструмент, поэтому не сильно концентрируем внимание на задачах. Предвосхищая вопрос, пилотируем HipChat и Teams
Зато про ChatOps могу сказать. Все началось как обычно на энтузиазме и постепенно вышло на уровень всего IT. В списке задач для СhatOps не только нотификации, но и такие вещи как получение списка задач из Jira, управление серверам (стоп/старт/рестар/постановка на обслуживание), управление релизами, создание аварийных чатов и т.д.
Часть этих задач уже пилотируется, но пока еще выбираем инструмент, поэтому не сильно концентрируем внимание на задачах. Предвосхищая вопрос, пилотируем HipChat и Teams
Вы писали, что разработчики коммитятся в свои dev-ветки, а когда функциональность готова, выкатывают изменения в общее хранилище. Команды работают с изолированными друг от друга частями приложения? Если нет, то каким образом решаются проблемы с merge при таком подходе?
Sign up to leave a comment.
Централизованный сontinuous deployment за год vol 2