Comments 48
Тестирование новых фич отдельно конечно круто, до первого глобального рефакторинга…

К такой эпической задаче нужно готовиться — закончить и слить все открытые ветки. А после этого все разработчики работают над рефакторингом, как я описал в 4м пункте процесса разработки. Или у вас есть опыт других граблей, кроме вылезающих повсюду конфликтов?

Какая качественная разница разрабатывать в отдельных ветках или разрабатывать и тестировать?

Можно глупый вопрос? Зачем нужен dev? Почему недостаточно фичи и мастера?

Если вы не выкатываете каждую фичу сразу же после мержа на прод, то как минимум два кейса:


  • чтобы знать, что в данный момент у вас сейчас на проде;
  • если вдруг понадобился срочный хотфикс, а у вас в мастере ещё не до конца проверенные последние изменения, чтобы не тянуть их.

Можно создать ветку release, но тогда функции dev просто примет на себя ветка master.

Тоже есть опыт отказа от development. Обе ваших проблемы имеют решения:


1) Хранить информацию какой тэг / последний коммит был последним задеплоен на прод — не так сложно.


2) В фича бранчу, перед мержем, подтягиваются ченжи из мастера, после чего прогоняются автотесты. Если они зелёные — можно мержить. Таким образом, код в мастере всегда стабилен и протестирован. Недостаток: если за время прогона тестов в мастер приехала другая фича, то, в идеале, надо снова подтягивать изменения и запускать автотесты. По факту, если команда не очень большая, а тесты быстрые, то такое случается редко. Да и вероятность того, что в обеих ветках тесты зелёные, а при мерже в мастер что-то сломается — низкая. И чтобы окончательно подстраховаться, тесты можно запускать после каждого мержа в мастер и запрещать деплой, если они красные. Но это, повторюсь, супер-пупер редкая ситуация.


Зато отказ от dev ветки приближает вас к continuous deployment, если есть такая потребность, конечно.

1) Как я в статье заметил, приведённый пример является лишь некоей готовой базовой идеей, от которой вы можете оттолкнуться, чтобы создать собственный workflow. Который будет соответствовать вашим потребностям, принятым практикам, философии)
Как, например, в приведённых ссылках на статьи от компаний, чье мнение однозначно стоит изучить, в принципе отказываются от принятой "классической схемы" и делают что-то своё. Даже каждая команда внутри одной компании.
Так что, конечно, вы можете договориться и обязать разработчиков тэгировать релизные пуши. Я решил уйти от этого "человеческого фактора" для упрощения процесса (хотя, конечно, можно и автоматизировать).


2) Это здорово, если в проекте у вас такое покрытие тестами, что вы безусловно верите зелёным галочкам. К сожалению, в моём случае тестами были покрыты лишь самые критические места.


Я думаю, к CD скорее приближает наличие такой необходимости (то есть, уровня продукта, требования к коду которого заметно вырастают, как я заметил в предупреждении к кейсу веб-разработки). А если вам это не нужно и предупреждённые пользователи вполне переживут запланированный на ночь минутный даунтайм, то лучше следовать правилу 80/20.

Первое ладно, а вот второе… Зелёные автотесты далеко не всегда говорят о том, что можно смело релизить


А дев ветка CD особо не мешает

чтобы знать, что в данный момент у вас сейчас на проде

Эээ. Мастер, нет?


в мастере ещё не до конца проверенные последние изменения

Эээ. Это как? И что такое тогда "до конца проверенный мастер“?

  • Что-то из ветки мастер, да. Но какой коммит? До или после той фичи, когда мы где-то тут (где сломалось) и вносили изменения?


  • "до конца проверенный мастер“. Это состояние в "классической схеме" соответствует итоговому состоянию release-ветки перед мержем в мастер. Эта ветка вам понадобится, если у вас ведётся разработка настолько интенсивно, что, когда вы интегрировали большое количество изменений, вам нужно время "устаканить" все возникающие при этом конфликты (stable-версия), когда при этом летят уже новые готовые изменения. Чтобы не быть в состоянии постоянного тестирования)


В dev собираются все фичи, тестируются, если все окей, то делается релизный merge request в мастер

Если тестирование длительное, то часто имеет смысл создать релизную ветку отдельную в какой-то момент, тестировать релиз на ней, а в дев продолжать мержить новые фичи, которые в этот релиз уже не пойдут.

Спасибо, хорошая статья, достаточно зрелый процесс получился. Я бы, наверное, чуть больше внимания уделил автотестам: например, вкратце рассказал про политику green build, когда мерж фича ветки с красными тестами физически запрещен, или про виды тестов и на каких этапах кто что пишет и проверяет. Сейчас создалось впечатления, что тесты просто где-то есть, но непонятно какое участие они принимают в процессе разработки.


После прочтения остался вопрос: какой именно механизм позволяет демонстрировать каждую фича ветку? На стэйджинге в один момент времени поднята только одна ветка? Если да, то нужно каждый раз руками деплоить? Или все? Или все с открытыми МР-ами? Если так, то как переходит переключение, и как экономите ресурсы когда одновременно поднято 10+ веток?

Спасибо за спасибо!


В принципе, повторюсь, конечно можно реализовать дальнейшие ограничения и автоматизации. Но в целом, GitLab не запускает следующие стадии, если предыдущая (с тестом) зафейлилась. А виды тестов — это скорее тема для отдельной статьи. Есть такой опыт борьбы с Selenium-ом. Если интересно — добавлю вариант в голосовалку для следующей статьи)


После прочтения остался вопрос: какой именно механизм позволяет демонстрировать каждую фича ветку? На стэйджинге в один момент времени поднята только одна ветка? Если да, то нужно каждый раз руками деплоить? Или все? Или все с открытыми МР-ами? Если так, то как переходит переключение, и как экономите ресурсы когда одновременно поднято 10+ веток?

Хорошие вопросы!


  • Демонстрировать позволяет то, что каждая ветка поднимает группу контейнеров по ключу --project-name, внутри которой стоит собственный реверс-прокси nginx и распределяет запросы. А вот на этом контейнере и вешаются уже ключевые метки, по которым Traefik и узнаёт, что появился новый сервис, на который можно перенаправлять запросы по правилу host=$CI_ENVIRONMENT_SLUG.dev.company.ru.


  • Поднимаются ветки только с открытыми Merge Request-ами. На стейджинге может быть поднято столько веток, сколько позволят ресурсы стейджинга. Именно вопрос экономии ресурсов заставил меня оставить кнопку выкатки в ручном режиме. Я пока так и не нашёл иного способа, чтобы не собирать ветки каждый раз при пуше (тэги тут неудобны). Буду рад, если поделитесь вашим опытом!


Спасибо за статью.
К вопросу о превью feature веток — что думаете про ситуацию, когда у вас несколько репозиториев и вместе с превью одного компонента нужно еще десять задеплоить рядом? Решали такую задачу?

Так понимаю, речь о микросервисной архитектуре? У нас пока монолиты, но вот мои рассуждения:
Такая архитектура уже говорит о том, что проект довольно серьёзный, так что и располагаемые ресурсы должны быть соответствующие. Скорее всего, всё должно строиться уже на платформе Kubernetes. Оркестраторы, кроме прочих задач, в том числе должны помогать решать вопросы сложных архитектур и процессов разработки. Без дополнительной информации могу предположить только решение "в лоб" и затратное по ресурсам: да, таки "деплоить ещё десять рядом". По тому, как это реализовать — зависит от вашего приложения. Наверняка понадобятся ещё дополнительные инструменты для хранения артефактов вроде JFrog Artifactory, Nexus и т.п.

Мы деплоили все 11. Было соглашение, что ветка начинается с номера задачи, скрипт пробегался по остальным репам, смотрел есть ли ветка с тем же префиксом и деплоил её, если нет, то деплоил dev/master ветку для остальных сервисов — образы для них обычно уже сбилжены. Или конфиг с ветками/тагами/коммитами какой сервис как поднимать.


Думали в сторону поднимать только измененные сервисы, но изначально была концепция "каждому енву свой енеймспейс" и с динамических фича енвов сходу не получилось достучаться до статических дев или тест енвов

Поднимали как-то по веткам по статусу задачи в джире. QA переводит задачу в Testing и поднимается ветка на отдельном поддомене. Возвращает или переводит в Tested — окружение убивается

Интересная идея, спасибо! Ещё и заставляет поддерживать статусы в соответствии.


Но хотелось бы решение продумать ещё дальше и не ставить необходимость гонять статус туда-обратно, чтобы, когда при тестировании сделали замечания и, пока просто делаются промежуточные коммиты, не вызывать на них сборки.

Как раз хотели с помощью технических средств ещё и подтолкнуть к обновлению статусов задач актуальных. Пускай даже тестировщик забудет сразу вернуть задачу на доработку, но чтоб протестировать ему придётся статус у задачи изменить, пускай на секунду, но поставить в "returned" — уже можно смотреть аналитику типа как часто задачи возвращаются к разработчикам

А, выкатку производить только в момент переключения. Да, мне нравится. Думаю, получение одного этого совета окупили труды по написанию статьи. Спасибо!

Свой Gitlab это конечно классно, но в контексте статьи "для молодых команд" в подавляющем большинстве случаев излишне.


Облачный Gitlab не нужно поднимать/разворачивать, гораздо меньше нужно настраивать, а обслуживать не нужно совсем, как и держать под него сервера и дисковое пространство.
Существующее в облачном Gitlab ограничение в 10Gb на репозиторий позволяет вполне комфортно работать и вполне зрелым командам, особенно в условиях микросервисов, когда репозитории относительно небольшие.


Деплоить по latest тегам некорректно и считается не очень хорошей практикой. Например, в случае imagepullpolicy: ifnotexists получите проблему. Деплой по тегу с версией правильнее.

В целом соглашусь про облачный GitLab, но в самое главное ограничение — 400 минут для Pipeline-ов вполне вероятно упереться и начинающим. Хотя, если настроите раннеры на своих мощностях, то они не считаются. Но тогда в целом и свой GitLab не так уж и трудно конфигурируется. Все настройки приведены тут, даже для случая за реверс-прокси, в чем и смысл данной статьи. Ну и за этот год уже были случаи, что облачный гитлаб падал, а мы спокойно продолжаем работу.


По поводу latest тэгов. Да, при использовании общественных образов с докерхаба, лучшая практика — привязываться к версии. Но для собственных образов это уже без особой разницы — вы же сами ими управляете. Зато так чуть проще файл конфигурации прода — не нужно передавать тэг для выкатки. Ну и быстрее понять, если что-то не так.

1) Естественно речь о своих раннерах, которые поднимаются элементарно.


Текущая современная инсталляция self hosted Gitlab (а не omnibus, который deprecated) состоит из более чем 20 контейнеров и более чем 12 вложенных Helm Chart'ов и установка и поддержка этого хозяйства новичками точно не проста и не ясно зачем нужна, кроме специфических кейсов.


Мнение по-поводу "облако падает" в целом ошибочно, т.к. то, что обслуживаете вы или кто либо другой уровня "небольшая команда" тоже нужно обновлять, патчить и т.п. + ваш uptime при работе 1-2 инженеров поддержки будет точно хуже, чем специализирующейся на этом команды инженеров поддержки Gitlab у которых это всё работает в GKE. Они упали дважды за несколько лет и это крайне хороший показатель, а после подробных portmortems доверие к ним только возросло.
Я видел и вижу облачные инсталляции Gitlab на достаточно крупных проектах и их это не потревожило.
Это примерно как не доверять серверные мощности AWS.


2) В случае, если вы используете эффективную политику Kubernetes imagepullpolicy: ifnotpresent, то при использовании latest при обновлении образа ничего не произойдёт, а делать always не эффективно.
У Gitlab есть прекрасные встроенные переменные окружения, которые как раз и созданы для автоматизации и реализуется использование конкретного тега элементарно. Например:
envsubst < $CI_PROJECT_DIR/k8s/dev-k8s.yml | kubectl apply -f -
А в самом dev-k8s.yml в качестве образа прописывается $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG
Прекрасно работает где-то уже годами. Естественно пример с kubectl, конечно, упрощённый, но мысль, надеюсь, ясна.


И как раз быстрее понять что не так, если указан конкретный образ и с 1.0.1 на 1.0.0 автоматизированный откат гораздо красивее реализуется.

1) Да, возможно для начинающих действительно проще воспользоваться готовым решением в облаке. Правда есть параноики, кто не любит держать свой код непонятно где и имеет собственные свободные серверные ресурсы в распоряжении. А ещё, с чего вы взяли, что omnibus deprecated? Нигде не найду таких тревожных новостей.


2) С Kubernetes не работал, поэтому ничего добавить не могу. Считаю, это "слегка" оверкилл для молодых команд :)

1) Возможно я поспешил с deprecated, но посмотрите их уже достаточно старое видео по распилу Omnibus и переходу на микросервисную архитектуру www.youtube.com/watch?v=rIUth_KrJdw (кстати в целом хорошее видео) +, например, docs.gitlab.com/charts говорит о «This is the official, recommended, and supported method to install GitLab on a cloud native environment.»
Так что новым инсталляциям точно не стоит использовать Omnibus, если он ещё не deprecated, то about to.

В облачном Gitlab можно и pci dss пройти, но параноики, которые боятся того же AWS/GKE есть, да :)

2) Нужно сразу использовать правильные практики. Использование latest как минимум очень желательно избегать.
Kubernetes это мейнстрим для практически любых проектов, которые планируют сколько-нибудь серьёзную нагрузку или удобное обслуживание и т.д., поэтому привожу пример.

Разворачивание Kubernetes, например, в том же GKE элементарно, вопрос зрелости команды разработки и DevOps.

Более того, молодым стартапам получившим инвестирование гораздо проще и быстрее развернуться именно в AWS/GKE, а когда проект действительно взлетит и начнёт сильно расти, то резать расходы и то часто и в облаках расходы можно существенно уменьшить за счёт использования spot instances / preemptible vms + cluster autoscaler и других техник.
on a cloud native environment.

Єто именно для запуска в облаке/кластере. Конечно, не стоит пытаться установить omnibus в k8s кластере, но если кластера нет и не предвидится особо, то omnibus вполне рабочее и стабильное решение. Вряд ли его выпилят до того как объявят GitLab как k8s only


Разворачивание Kubernetes, например, в том же GKE элементарно

Пока для меня ключевой вопрос: готова ли компания вкладывать тысячи долларов в месяц (только на железо, плюс увеличение стоимости поддержки) отказоустойчивость и горизонтальную масштабируемость. Если нет, то очень часто k8s технически и экономически избыточен, заметно затрудняет разработку на первых этапах и мало помогает в дальнейшем, кроме как для резюме. ))

Уже уходим немного в холивар, но

1) в целом весь этот стек можно поднять и в docker-compose (но не нужно).
2) Gitlab всё же ориентируется на серьёзную разработку, где K8s практически неизбежен.
3) Даже если вы разрабатываете не в docker, то держать такие сервисные вещи, как сам Gitlab удобнее именно в нём по ряду причин, а значит см 1, 2 и 4.
4) Лично у меня, как и у многих разработчиков, K8s стоит на локальной машине в виде K3s, кушать не просит и он гораздо удобнее, чем compose. Имхо именно так нужно разворачивать локальную среду для разработчиков в 2020. Любой микросервис и даже стек микросервисов работает на моей машине идентично проду (если только не нужна база с 370gb ram :)
4) Никаких тысяч долларов не нужно. Это заблуждение основанное на недостатке опыта. Для особо экономящих для начала (или в особых случаях ) и мастера, совмещённые с воркерами, подойдут: видел такие автономные мини кластеры, например, на складах.
5) «затрудняет разработку на первых этапах» зависит от зрелости разработчиков. Имхо лучше потратить немного времени на изучение полезной технологии на старте, чтобы выиграть гораздо больше в перспективе.
6) K8s в резюме уже никого не удивишь. Удивляют уже те, у кого его там нет.

2) k8s и/или облако неизбежены там, прежде всего, где нужно автоматическое горизонтальное масштабирование и подобные штуки
3) в принципе согласен, но вот писать самому тот же docker-compose для GitLab так себе идея для обічного разработчика, по-моему
4) Идентично проду он работает, если на проде k8s ) У нас вот всё по старинке, bare metal + linux + nginx + fpm + mysql. И локально у всех дублирует. Чисто для локальной разработки докеризировать и кубернетизировать приложение ( немногим меньше десятка php сервисов плюс базі, редисы и т. п.) не скоро окупится, имхо. Так-то у меня стоит по старой памяти minikube, но бездействует сейчас. А вот на прошлом проекте поднималось всё в minikube (правда в virtualbox тормозило, сделали native), но для локальной разработки приходилось кучу костылей внедрять в чарты системі, например, чтобы локальные каталоги монтировать в php контейнеры. Да и с дев-серверами react-приложений проблемы были. C PV/PVC частенько, разные, но именно связанные с концепцией k8s локально. Основной способ решения проблем возникаюших в процессе разработки был снесение кластера и установка его заново.
4) Кластер из трёх нод с 2 CPU и 7,5 гб RAM стоит почти 300 долларов в месяц у Гугла. Плюс, если уж у Гугла хостимся, то там где-то рядом надо поднимать базы (пара инстансов 8х8 — почти 400 долларов в месяц без учёта дисков), сервер для nfs под PV — считайте слабенький кластер на 6 ядер и 24 Гб ОЗУ (у меня ноутбук мощнее) плюс база и nfs сервер — больше 1000 долларов. И таких наборов минимум два: прод и дев
5) вот выигрыш весьма сомнительный если особых требований нет
6) навскидку только в процентах 30 интересных мне вакансий в Киеве хотя бы докер мелькает.

K8s практически неизбежен на масштабах. И не только при горизонтальном, но и при вертикальном масштабировании.


Масштабы = много людей на которых тем или иным образом происходит заработок. И наверное всё же стоит ориентироваться на это, а не на пет проекты, хотя, повторюсь, локальный K3s, да и K8s прекрасно работают при должной настройке и подготовке.


Но даже если клепать пачками одностраничники на пыхе, то их можно достаточно удобно разместить в кубе, а не за одним большим nginx с кучей vhosts и одной большой базой. Да, бывает и такое и оно работает, но может быть лучше, проще в обслуживании, отказоустойчивее и ещё много других но.
Куб и bare metal вполне себе нормально живут. Более того, иногда позволяют реализовать очень интересные решения, когда близость к железу всё-таки реально необходима.
Естественно Google дороже on prem, но всё это зависит от ваших целей, задач, реализации и сроков, от того насколько вы можете позволить себе downtime на обслуживание и многое другое.


Недавно работал с проектом, у которых кластера с кучей bare metal машин в откровенно хреновеньких дц, которые были в среднем загружены процентов на 10 по cpu и на 20 по памяти.


Переход в GKE/EKS позволил им освободить руки инфраструктурной команды и использовать гораздо лучшую инфраструктуру, которая не так часто падает, как текущая за те же деньги. Бизнес доволен, что не теряет деньги под нагрузкой (а нагрузка там есть), команда получила возможность делать больше и не заниматься чепухой. Это ли не прекрасно.


Я не знаю что у вас за интересы, на чём вы пишете и т.п, но разработчики не знающие докер уже в меньшинстве, во всяком случае в моём окружении.


Немного пройдитесь по issues самого Gitlab: много где issues связанные с omnibus получают низкий приоритет и похоже не будут решены никогда, что говорит само за себя.

Но даже если клепать пачками одностраничники на пыхе, то их можно достаточно удобно разместить в кубе, а не за одним большим nginx с кучей vhosts и одной большой базой.

В кубе "на коленках" же то же самое получится. Тот же nginx, пускай с красивым названием Ingress. И базы так же будут. (в докер, поднятый "на коленках", тащить базу (SQL) так себе идея, имхо, особенно пытаться кластер базы организовать).


Недавно работал с проектом, у которых кластера с кучей bare metal машин в откровенно хреновеньких дц, которые были в среднем загружены процентов на 10 по cpu и на 20 по памяти.

Так я же не спорю. Если у них уже кластера, то им нужно масштабирование. Я же по компании у которых пальцев на одной руки хватит пересчитать сервера в продакшене. И даже если загрузка их 10-20%, то экономии не выйдет, поскольку для нормальной инфраструктуры от гугла или амазона потребуется больше инстансов с большим количеством CPU и RAM.


Я не знаю что у вас за интересы, на чём вы пишете и т.п, но разработчики не знающие докер уже в меньшинстве, во всяком случае в моём окружении.

В моём окружении наоборот. Вернее многие знают, пользовались на прошлых проектах тем, что кто-то настроил, но вот энтузиазмом переводить и поддерживать на докер системы самим не горят. Можно сказать я один такой в своём окружении. При том, что мой энтузиазм ограничивается docker swarm — это то, что я с удовольствием использовал на одном проекте в проде и то, что с удовольствием использую локально и на своих вдсках для пет-проектов. Кое-чего не хватает, что есть в кубе, но почти всё компенсировал или отдельными контейнерами, или обвязкой на баше (куб в моих руках тоже без неё не обходится). Но вот инициировать или активно поддерживать перевод проектов на кубер я не хочу — страданий мне и так хватает.

В кубе «на коленках» же то же самое получится. Тот же nginx, пускай с красивым названием Ingress.

Никто не просит собирать куб на коленках.
Ingress + daemonset на том же bare metal работает гораздо интереснее и производительнее, чем какой-то один хост с одним reverse proxy. И можно использовать одновременно несколько ingress под разные задачи.
И базы так же будут. (в докер, поднятый «на коленках», тащить базу (SQL) так себе идея, имхо, особенно пытаться кластер базы организовать).

Patroni и всякие операторы норм работают, но базы можно и не докеризовать, от этого с ними приложения работают не хуже.
Но у микросервисов принято иметь свои небольшие базы и они прекрасно работают в контейнирезованном виде.
И даже если загрузка их 10-20%, то экономии не выйдет, поскольку для нормальной инфраструктуры от гугла или амазона потребуется больше инстансов с большим количеством CPU и RAM.

Нагрузка динамически меняется и если держать её на адекватном уровне 60-80%, а под пиковое время по расписанию готовить прогретые ноды, чтобы они входили в строй быстро, то экономия очень даже будет. Не забываем использовать spots/preemptive.
страданий мне и так хватает

Моя цель: уменьшение time to market и на серьёзных проектах с кубером и автоматизацией это происходит.

Под "кубом на коленках" я имею в виду k8s поднятый по туториалам, без особого понимания чем kubelet отличается от kubectl (утрирую, но не сильно)


А вообще, мне кажется, что мы говорим в каких-то совсем разных контекстах. Я о проектах, где без докеров-кластеров достаточно одного хоста под основную пиковую нагрузку. 2+ хосты если и вводятся, то для выноса неосновных нагрузок с основного хоста. Типа очередь почты можно обрабатывать и на отдельном хосте, а отчёты в админке формировать с реплики основной базы. Про проекты где, грубо говоря, каждый новый сервер нужно с боем выбивать у менеджмента. И имеющиеся сервера все технические и даже не очень работники знают поименно :)


Вы же, кажется, по проекты, где толком никто и сказать не может сколько серверов прямо сейчас на проекте, если не лезть в мониторинг какой-то. А хостнэймы серверов вообще никого не интересуют, или они сугубо утилитарны типа cluster1master2


Моя цель: уменьшение time to market и на серьёзных проектах с кубером и автоматизацией это происходит.

Вы не поверите, но моя тоже. Но на интересных мне проектах кубер его замедляет. Отнимает ресурсы разработчиков на борьбу с ним или с админом ака "девопс", если вдруг повезёт и в команде таковой имеется.

1) 10 Gb достаточно мало когда образы по 1+ Gb и на каждой ветке образ строится даже если по одному репозиторию на сервис
2) некоторые любят монорепы, даже в условиях микросервисов
3) Гитлаб вполне нормально поднимается "локально" и особо есть не просит

1) Образы по 1Gb+ звучит очень очень плохо.


2) Как раз сегодня наблюдаю использование облачного Gitlab в монорепе с ~ 10 Java "микросервисами". Но лучше так не делать.


3) У вас просто мало проектов и нагрузки и опять же: зачем что-то обслуживать и держать под это (=платить за) серверные мощности, диски и т.п, если это можно не делать. Освободите руки себе и коллегам и займитесь чем-то другим.


Например, у вас уже 13.5.3?
И postgres нормально реплицируется и выдержит выход из строя дц без downtime?
И cdn для разработчиков из разных стран нормально работает?
И.т.д


У меня, там где облако, на всё да и это сотни деплоев в неделю как минимум.

1) Заметно уменьшить можно только полностью перестраивая архитектуру приложения, разбивая один образ на 1 Гб на десяток по 200Мб.
2) Монорепа заметно облегчает синхронную разработку и деплой разных сервисов. По сути в ветке содержится вся система полностью
3) Не то что мало, он один ) Но 10 Гб для него мало. А облако, насколько я помню, не даёт докупить места даже. При том, что за лицензии платим.


Сейчас не знаю, что на прошлом проекте, на текущем ТимСити онпрем, последняя версия

1) я не знаю ваш стек, но 1Gb образы это не нормально
2) дискуссии о монорепозитории vs нескольких репозиториях стары и естественно присутствуют в том числе на хабре. Выводы, видимо, каждый делает сам. Но я не видел ни одного кейса, когда монорепу нельзя было бы раздробить используя правильные инструменты и техники, а уж для тех, кто начинает с нуля создавать монорепу и приучать себя к "плохому" не стоит. Конечно это несколько другое, но всё же монорепозитории попахивает монолитом или псевдомикросервисами. Сколько я таких видел даже и не перечесть, когда всё это хозяйство в 1 базу ходит.
3) значит вероятно именно вы попали в меньшинство тех проектов, которым нужно больше, чем 10Gb на репозиторий. В статье ведь речь не конкретро о вас. Работая в том числе в DevOps консалтинге и имея определённую "насмотренность" различными проектами, а также общаясь с народом в профессиональных кругах могу сказать, что реально 10Gb на репозиторий это вполне достаточно, особенно если правильно настраивать clean policy и т.д.


Вы поняли о чём я, on prem по определенным метрикам всегда будет проигрывать облаку и наоборот. Важно понять что даёт вам максимальную эффективность и не является ли что-то скорее какими-то вашими религиозными убеждениями или просто привычками, чем логическим обоснованием использования той или иной технологии или техники.


Я утверждаю, что жить можно без on prem и в очень больших масштабах, но нужно определенным образом организовать это и это будет эффективно. Но так можно сделать не в 100% случаев.

Я утверждаю, что жить можно без on prem и в очень больших масштабах, но нужно определенным образом организовать это и это будет эффективно.

У меня утверждение основное вроде противоположное, а вроде и нет: до масштабов, когда инфраструктура станет выгодной в облаке ещё дорасти надо. Если по не физическим масштабам проекта, то по суммам имеющегося на инфраструктуру капитала. Вот стартапу, который поднял большие инвестиции я первый посоветую: берите команду сеньористых девопсов и гоу в облака. А вот компании, которая не может позволить себе нанять второго технического специалиста с моим уровнем оплаты, только джунов и миддлов в помощь к одному то ли сеньору, то ли CTO по факту идти в облака активно — нет. Даже если я в ней не работаю, а уж если работаю...

Использование облаков без больших трат и даже на уровне bare metal, а иногда и меньше, возможно, но для этого необходимо очень хорошо разбираться в техниках, которые помогают адекватно использовать ресурсы и в целом в выстраивании архитектуры проектов под это и тут к каждому проекту должен быть индивидуальный подход.


Ваше утверждение для меня слишком общее, чтобы судить о чём то конкретно.


К тому же облака нынче разные. Тот же Hetzner с недавних пор позволяет через Kubernetes контроллер (https://github.com/hetznercloud/hcloud-cloud-controller-manager) выписывать не только инстансы, но и load balancer'ы и т.п. и тут уже можно выстраивать вполне интересные вещи, не на уровне aws, конечно, но гораздо интереснее и динамичнее того, что позволяют bare metal и за ещё меньшие деньги.
Хотя spot/preemtible машин у них всё равно нет. А ещё есть spot.io и много другого.

Использование облаков без больших трат и даже на уровне bare metal, а иногда и меньше, возможно, но для этого необходимо очень хорошо разбираться в техниках, которые помогают адекватно использовать ресурсы и в целом в выстраивании архитектуры проектов под это и тут к каждому проекту должен быть индивидуальный подход.

На железе можно сэкономить, наверное, и на небольших проектах с помощью облаков и прочих серверлесс, но вот далеко не факт, что получится сэкономить в целом. Специалисты, которые очень хорошо разбираются в облачных/кластерных техниках, да ещё могут выполнять роль системного архитектора, стоят заметно дороже по сравнению со специалистами, которые разбираются с классическими техниками и могут выполнять роль архитектора приложений/решений.

Интересное совпадение, идея похожей статьи пришла мне в голову 3-4 дня назад. Тоже показалось, что никто не рассказывает "от и до". Приглашу почитать, как закончу :)

Это здорово. С удовольствием ознакомлюсь с другими точками зрения)

Большое спасибо за статью, очень помогла многие вещи расставить по своим местам. Это просто находка для человека пытающегося из сисадмина эволюционировать в DevOps, таких статей днём с огнём не найти :) Пишите, пожалуйста, ещё!
Что вы по итогу деплоите? Фичи, микросервисы, конфигурации, просто код, приложения?

Как организационно разрешается следующая ситуация:
1) есть куча фич, часть из них проверена и принята, часть нет.
2) на совещании вы запланировали публикацию этих фич через неделю, но процесс принятия новых фич продолжается и у вас вырастает одна большая куча из фич, в которой часть идут на публикацию и фич, которые еще не идут в прод. (это, скорей всего вопрос про интерфейс или способ управления этим процессом)
?

Не понял первый вопрос про то, что деплоим. Веб-приложение в интранете организации. Можно сказать, SaaS. Монолит.


Второй вопрос, если он про интерфейс — то в гитлабе всё это сделано очень удобно (ведь сам гитлаб разрабатывают в гитлабе, у них там сотни фич висят в работе). Вы можете практически любой свой воркфлоу оформить с помощью меток к задачам. Также у вас есть доска (типа Kanban), которая тоже работает на метках. А способ управления по-моему один — все участники процесса должны ревностно относиться к консистентности информации в задачах (см. 2й пункт обязательных составляющих типичного процесса разработки).

Only those users with full accounts are able to leave comments. Log in, please.