Comments 7
Не ясно следующее - мы мержим нашу фичу в мастер, и потом начинаем тестировать ее. В это время кто-то от мастера сделает бранч для своей фичи, и получается, что он использует код с багами из мастера. Как быть?
Не совсем, мы создаем feature-ветку от мастера. Пишем в ней код, затем именно эту ветку раскатываем как stage-environment (в моем примере с помощью k8sbox) и тестируем ее отдельно от dev/prod окружений.
Как только фича протестирована - мы мержим ее в мастер. Из мастера можно настроить автоматический деплой в dev-environment при каждом новом пуше.
Перед публикацией релиза в прод - желательно проверить как будут вести себя все ваши фичи на dev-окружении, не будут ли они конфликтовать друг с другом.
Если все ок - отбиваем тег и выкатываем в прод. Если какая-то фича с багом - делаем revert мерж-коммита конкретной фичи и отправляем на доработку, а релиз выпускаем без нее.
В мастере желательно хранить только протестированный на stage-feature-окружениях код. Однако если все же баг нашли в мастере и от него уже ответвились другие разработчики - после фикса и мержа этого фикса в мастер - пускай они просто подтянут новые изменения перед созданием своего merge-request
k8sbox get environment // list of saved environments
По параметрам подразумевается как раз вторая команда - дать инфу по окружениию. Лучше что-то типа listenvs (если нет других команд с list, или list envs, если есть).
k8sbox describe...
Очень длинное слово. Лучше view, show, info.
k8sbox delete -f environment.toml
А почему бы не сохранять toml-файл в установленном окружении. Тогда удалять окружение можно (и нужно, по логике) по имени -
k8sbox delete envID
P. S. Кстати, именно такой подход (свое окружение на каждую фичу и несколько интеграционных QA-envs) был в нашем проекте.
Я старался сделать интерфейс схожим с kubectl и его командами, так как планируется добавлять множество команд для просмотра статистики и разделения уже задеплоеных окружений. get и describe кажутся идеально подходящими, хотя вероятно стоит добавить к ним шорткаты.
А почему бы не сохранять toml-файл в установленном окружении. Тогда удалять окружение можно (и нужно, по логике) по имени -
Изначально был план сделать отдельный файл для окружений, по примеру с terraform, однако понял что будет излишне. Отсюда и такой не очень интуитивный механизм удаления
environment.toml всегда лежит где-то рядом обычно, скорее всего в репозитории в котором лежат другие деплойменты. Однако сами окружения (их описания) сохраняются в /tmp/k8sbox/saves в json формат. Именно так можно посмотреть что мы уже раскатили и детали окружения с помощью команды k8sbox describe {EnvironmentID}
Удаление по ID окружения - как раз то над чем сейчас работаю, будет уже на неделе, как, думаю, и шорткаты для основных команд)
Но вы понимаете, что вот тут:
k8sbox get environment // list of saved environments
Команда противоречит описанию? Ну хотя бы тогда get envs или get environments.
Я не знаю kubectl, но обычно, если команда состоит из двух отдельных слов, то значит, второе слово это параметр, который может меняться. Ну приставьте себе вместо команды dir что-то вроде get files. Юзер сразу думает, а что еще можно "гетнуть"? А ничего.
Не вижу тут противоречия, если честно, из официальной документации kubectl:
# Get commands with basic output
kubectl get services # List all services in the namespace
kubectl get pods --all-namespaces # List all pods in all namespaces
kubectl get pods -o wide # List all pods in the current namespace, with more details
kubectl get deployment my-dep # List a particular deployment
kubectl get pods # List all pods in the namespace
kubectl get pod my-pod -o yaml # Get a pod's YAMLОднако команда kubectl get pod равнозначна команде kubectl get pods
В ближайшем будущем появится возможность просматривать не только активные окружения, но так же и другие сущности, как и фильтровать их по имени окружения, активным боксам и так далее. Команда get идеально подходит для таких вещей, а сущности, которые мы хотим получить, могут иметь кучу удобных для пользователя алиасов.
На другом примере из kubectl можно посмотреть на команды ниже, которые вернут один и тот же результат.
kubectl get services
kubectl get service
kubectl get svcСкорее всего в следующей версии k8sbox будет реализовано получение списка окружений с помощью следующих команд:
k8sbox get environments
k8sbox get environment
k8xbox get envЯ активно работаю над этим и стараюсь сделать проект максимально понятными для пользователя такого высокоуровневого инструмента как k8sbox. Однако если есть крутые идеи - с радостью буду ждать пулл реквестов)
Года четыре назад для решения этой проблемы начал делать ГУЁвую тулзу как опенсорс: https://github.com/jonasasx/envrouter. Опробовал примерно на 5ти командах, везде она очень заходит. Но нужна помощь в её развитии.
Кому интересно посмотреть демо, воспользоваться или присоединиться к разработке пишите в телегу jonasasx.
Решаем вечную проблему deployment bottleneck и репликации окружений