Comments 10
Мы сделали два отдельных репозитория (variables и secrets).
А Vault не рассматривали?
Рассматривали конечно, но в итоге решили, что на тот момент для нас это избыточно и остановились на https://github.com/bitnami-labs/sealed-secrets
Проблем с sealed secrets не было от слова совсем, а vault нам пока так и не пригодился. Если мы решим внедрять vault, то думаю и секреты переведем в него тоже
В моей практике часто для тестирования задач требуется менять переменные окружения. Таким образом, для одной задачи нужны одни значения, для другой — другие. Как вы решаете эту проблему или у вас её не существует?
Насколько я понял, у вас нет фиче-стендов. Как решается проблема того, что сегодня Петя и Вася смержили в stage свои задачи, но в Петиной задаче баг, а Васину нужно сегодня выкатить в прод?
Такие проблемы есть, хоть и редки (тут никуда не деться, когда среды общие). На память приходит проблема, когда для одной задачи нужно короткое время жизни токена, а для другой подольше. Но, учитывая что по версионированию в гите видно кто вносил изменения такое решается горизонтально.
Что касается фича стендов, то они у нас есть. В рамках этой статьи не стали про них писать, ибо там тоже есть о чем рассказать). Мы используем https://www.rancher.com/ для этого и поднимаем стенд, если видим, что задача долгая или по запросу команд.
По стендам у нас еще действует следующие договоренности: на стейдже мы тестируем фичу и только. Стенд может быть нестабильным и туда может вливаться много задач. Конфликты решаются горизонтально в командах.
На препрод проводятся интеграционные тесты и если нужно какие то автотесты. После тестов уже идет релиз конкретной оттестированной задачи на препроде в прод с прохождением обязательных автотестов.
Каким образом происходит деплой изменений в БД? Например обновилась stored процедура, или новый column добавился в какую-то таблицу?
А что если изменилась stored прцедура и плюс какая-то логика в приложении? В таком случае надо деплоить изменения в обоих частей (приложение и бд) одновременно.
Каким образом отслеживается таск созданный со стороны бизнеса в тикет системе? Есть ли интеграция ее с gitlab?
stored процедур у нас архитектурно нет. Миграции разрабатываются с учётом обратной совместимости и на стендах это достаточно легко ловится.
С учетом этого миграции на прод в 90% случаях проходят без проблем. Если по каким-то причинам мы понимаем, что совместимости нет и миграция в один конец - то планирование релиза в ненагруженное время с деградацией. Но с учетом микросервисов если влияние и бывает, то только на часть функционала.
По интеграции - да есть интеграции jira и gitlab. К задаче прилинковываются MR и видно кто что делал. При создании релиза в gitlab там указываются связанные jira задачи и дальше по кнопкам создаются релизные задачи где это все линкуется, а по закрытию - закрывается задача и делается нотификации (об этом я писал выше в статье)
Приятно что вам понравился helmwave. Интересно, а с какой версии вы его используете? Я думаю другим было бы полезно увидеть helmwave.yml как он у вас построен.
Я бы на вашем месте еще бы строже отнеся к названиям стадий в gitlab-ci. И придерживался какого-то одного стиля: kebab-case/snake_case/props::case.
В целом путь похож очень сильно на тот, что и прошла наша команда.
Точную версию не вспомню, но это 2020 год, возможно даже с одних из первых версий используем :)
helmwave.yml.tpl
---
version: 0.25.0
project: {{ env "APP_NAME" }}
releases:
- name: {{ env "RELEASE_NAME" }}
namespace: {{ env "NAMESPACE" }}
environment: {{ env "CI_ENVIRONMENT_NAME" }}
chart:
name: ./chart
atomic: true
maxhistory: 10
resetvalues: true
wait: true
timeout: 360s
values:
- ./chart/values.yaml
- ./chart/values-common.yaml
- ../{{ env "APP_NAME" }}/helm/values-base.yaml
- ../{{ env "APP_NAME" }}/helm/{{ env "VALUES_FILE" }}
- ../special-project/helm/{{ env "VALUES_FILE" }}
recreate: false
По комментариям спасибо, учтем.
Здравствуйте! Много читал и сам всегда думал, что ТТМ(Time to market) надо уменьшать. В вашем тексте несколько раз упоминается, что ТТМ надо увеличивать. В начале статьи это есть, подумал опечатка бывает. Но далее по тексту снова встретилось: "Работая над увеличением ТТМ, мы понимали, что возможность катить быстро и прозрачно (с откатами) — это must have."
Это опечатки, или все-таки я не правильно понимаю, что ТТМ должен стремиться к минимуму?
Эволюция процессов CI/CD в more.tv