Comments 26
И мышкой всё, мышкой.
А потом в сложной конфигурации кто-то куда-то нажал и всё пропало.
Это как раз не проблема — настраиваем хранение настроек в гите и можем откатиться. Есть, правда, вопросы к тому, как хранятся пароли и ключи в таком случае. Другое дело, что руками эти файлы редактировать "наугад" так себе затея, а мануала хотя бы подобного этому я не нашёл. Остаётся клацать в GUI сохраняться и смотреть диффы. Пробовать что-то сделать и наблюдать как даже не загрузка конфигов, а их компиляция падает.
1. На каждой странице настроек конфигураций есть кнопка View in DSL — она позволяет увидеть, как будут выглядеть ваши текущие настройки в Kotlin формате
2. На уровне проекта можно скачать полное описание проекта и его конфигураций в Kotlin, если зайти в настройки -> Actions -> Download settings in Kotlin format
3. Ну а из почитать есть серия постов про Kotlin DSL, документация и вот этот доклад про то, как начать использовать Kotlin DSL в своих проектах.
Вот никак не могу придумать как реализовать с этим набором несколько простых сценария:
1.билд любой ветки и деплой её на дев-сервер с обязательным запросом ветки, без дефолта
2.на коммиты в develop билд её и деплой туда же автоматически (это сделал кое-как, правда билд докера не кэшируется)
Крайне желательно чтобы было видно какая ветка задеплоена без копания в логах
3.1 На коммит в мастер билд и деплой на стейджинг сервер автомвтически
3.2 Запускаются тесты на стейджинге, формируются отчёты, QA получает уведомление, в идеале с ссылкой на апрув
3.3 пайплайн ставится на паузу
3.3 QA жмёт апрув, билд деплоится на прод
- Аналогично 3.1+3.2 для лобой (пускай с шаблоном hotfix-*)
При этом какое-то переиспользование хорошо бы (про шаблоны знаю, но ещё не разобрался), в частности совсем не хочется создавать три конфигурации для дева, стейджа и прода, которые отличаются только десятком-другим параметров, но создавать 30-60 параметров типа prod-db-host, dev-db-host… не хочется. Типа хэшмапы есть что-то, чтоб в параметрах задать конфиги для каждого енва в одном месте и дёргать их из разных конфигураций и шагов?
1.билд любой ветки и деплой её на дев-сервер с обязательным запросом ветки, без дефолтасоздание отдельного билда(для нужной выбранной ветки) Вам не подходит? Можно даже скопировать конфиг дефолтного билда, а потом просто внести правки в меню «Version Control Settings».
п.2 описан сумбурно. Если правильно понял, то тут можно написать bat, который выполнит необходимые процедуры.
Крайне желательно чтобы было видно какая ветка задеплоена без копания в логахЯ бы в пути артефактов вставил в выходной путь переменную %vcsroot.branchName%. Так не ошибетесь.
Рад буду, если мой комментарий поможет.
создание отдельного билда(для нужной выбранной ветки) Вам не подходит?
По сути 1 и 2 отличаются только тем, что 2 триггерится автоматически на коммиты в конкретную ветку, а в 1 при запуске нужно указать ветку/таг/коммит. На псевдокоде
onCommit('develop') {
ref = 'develop'
env = 'dev-server'
artifacts = build(ref)
deploy(artifacts, env)
}
onClickDeploy() {
ref = prompt('Enter git reference')
env = 'dev-server'
artifacts = build(ref)
deploy(artifacts, env)
}Я бы в пути артефактов вставил в выходной путь переменную %vcsroot.branchName%. Так не ошибетесь.
Хочется сделать чтобы неподготовленному пользователю с первого взгляда было понятно на каком енве какая ветка задеплоена, а не прописывать ему инструкцию по последовательности кликания по проектам и подпроектам, чтобы выяснить какие ветки каких репозиториев задеплоены на дев-контур.
Извините, в полпятого утра писал при нормальном графике...
Автоматические тесты небольшая проблема, но QA ещё на стейджинге руками клацают, в любом случае нужно ручное подтверждение переноса со стейджинга на прод. Желательно именно переноса, то есть билд на стейджинг и прод должен один и тот же деплоиться.
как вариант, правда на мой взгляд не очень правильный, можно создать 2 ветки в vcs и 2 билда соответственно. Одна для стейджа, а другая, дефолтная, для прода. Если все норм в стейджевой ветке — сливать изменения в дефолтную(заменит ручное подтверждение).
Еще вариант — управлять этим всем через Kubernetes.
Впрочем, подумаю, может еще идея какая-нибудь в голову придет.
Kubernetes точно не вариант на ближайший год.
Про ветки тоже думал, но сложно обеспечить выкладку на прод именно того билда, что был на стейдже — очевидный вариант по хэшу коммита различать артефакты не работает при мержах, если не обеспечивать fast forward only стратегию через rebase постоянные. Может ввести релизные таги и по ним как-то триггерить деплой на прод — хэш коммита не поменяется. Надо в эту сторону подумать. Может сделать отдельный (агрегированный) билдчейн, который QA будут пуками запускать, чтобы пробегался по репам и ставил и пушил таги, а уж на них как-то привязать триггер для деплоя на прод.
Вот здесь есть очень похожий чейн (можно зайти гостем): demo.teamcity.com/viewLog.html?buildId=2348&buildTypeId=GuestbookAws_Deploy_DeployStaging&tab=dependencies#_expand=block_bt18-2348
Настраиваю сборку Android-проекта в TeamCity Cloud, требуется указать ANDROID_HOME.
Не подскажете пример, где это указывается и как должен выглядеть путь?
Предполагаю, что это нужно прописывать в Build Step -> Command Line ->...
TeamCity: настраиваем CI/CD в вашей команде