Comments 40
Умение поправить что-то незначительное своими силами позволяет не тратить время на поход к коллегам
Да и вообще, почини нам чайник и принтер заправь, ты ж программист. И завтра вместо объявления двух вакансий: разработчика и инженера администрирования, работодатель объявит одну — разработчика, но с требованиями (и обязанностями), перенесенными из админской позиции. За, хотя бы, вдвое больше денег? Ха!
А послезавтра айтишники будут создавать один за другим посты, мол, что за напасть, зарплаты падают, а требования растут, почему всем вдруг стали нужны высококвалифицированные в двух и более областях специалисты за совсем скромные деньги.
В общем, тег "вредные советы" очень просится к этой статье.
Да, можно ещё бандлеры не изучать, лид там как-нибудь что-нибудь соберёт, и можно 2 кнопки ждать install/run..
Конечно, в идеале должен быть человек, который возьмёт на себя девопс, настроит скрипты и тд
Но ждать человека, а если он ещё и в отпуске, чтобы поправить/добавить/убрать какую нибудь мелочь, например, уже не очень приятно и удобно, тк билд надо собрать уже сейчас
И, имхо, понимать что происходит в разработке на разных уровнях - именно то, что подразумевает работа инженера
Ещё работа инженера подразумевает общее понимание организационных процессов. Например, разграничение зон ответственности. Почему CI/CD именно таков? Потому что администраторы, я уверен, провели исчерпывающий vetting возможных вариантов и на текущий момент остановились вот на том, что имеем именно сейчас. И они подписываются под тем, что они готовы сопровождать именно это решение и именно в таком виде. Любые изменения в этой реализации, исходящие от них же, означают, что с момента внесения изменений они также принимают на себя и ответственность за работоспособность. И тут приходит разработчик, которому "очень срочно, некогда объяснять и ждать", и начинает там наводить свои порядки.
Я проходил это на прошлой работе. После такого девопсы заявили: "вот там (ссылка на коммит) были внесены изменения в реализацию, и это не просто правка переменных, изменена логика, с того самого момента мы снимаем этот репозиторий с нашей поддержки, как минимум, пока это изменение не будет отменено". Им слова никто не сказал. И я полностью их понимаю.
Они отвечают за всё, что касается ресурсов, их резервирование, выделение, работоспособность, эффективное использование. Разработчики могут предоставить требования к программному продукту, и это обязанность девопсов (администраторов, эксплуатации) обеспечить именно такое количество ресурсов (я здесь имею в виду случай, когда требования по ресурсам объявлены в соответствии с процессами, а не произвольно "дайте пятьдесят EPYC, чтобы нам синус посчитать, я так хочу"). Но разработчики не имеют никакого права вмешиваться в работу уже настроенных окружений по своему хотению без, хотя бы, согласования с эксплуатацией. Даже ещё один новый "пустячный" этап в пайплайне может легко вывести процесс за пределы выделенных на него лимитов ресурсов. А отвечают за это девопсы (администраторы, эксплуатация).
Что касается аргумента про "девопс в отпуске", то, конечно же, надо обратиться к тому, кто не в отпуске. Если компания не считает нужным резервировать кадры (bus factor = 1.0), то это тоже не является хоть сколько-нибудь причиной для того, чтобы разработчик принимал возникшие в связи с этим риски бизнеса на себя. По крайней мере, без соответствующей компенсации.
Ну и вне этой темы, как ниже заметили: статья-то почему-то про гитлаб, а что делать тем, у кого GH Actions, Terraform, Azure DevOps, CloudFormation, и прочая и прочая? А если сегодня GHA, а завтра девопсы решили переехать на Azure DevOps (как раз с прошлой работы кейс)? Всем разработчикам тоже срочно бежать за девопсами учить? А в обратную сторону это работает, например, проект был на Python, а мы переезжаем на C#, девопсам надо бежать переучиваться, ведь "работа инженера подразумевает понимание, как это работает"?
Все эти штуки про пнуть залипшую таску, про запустить с другими параметрами и так далее берутся не из изучения CI/CD, а из представленной девопсами документации. Там этого может не быть, но тогда скорее пиши багрепорт, чтобы они поскорее твой кейс исправили или покрыли отдельно в разделе "что может пойти не так и как починить".
Спасибо, тебе мил человек, именно благодаря таким как ты, девопсы сильно востребованы и отлично оплачиваются.
А в обратную сторону это работает, например, проект был на Python, а мы переезжаем на C#, девопсам надо бежать переучиваться, ведь "работа инженера подразумевает понимание, как это работает"?
Да в обратную сторону это работает. Мы, девопсы, идем и разбираемся с тем как нужно собирать в новом языке и все переписываем, потому что - работа инженера подразумевает понимание, как это работает. Вот как раз недавно приходилось переделывать CI для проекта, который переходил с python на go.
P.S. Я для разрабов лекцию читал,чтобы они понимали как работать с GitLab CI. Это привело к тому что они его перестали бояться и стали вносить правки и фиксы.
Это не в обратную сторону. Я могу согласиться, что разработчики могли продолбаться с описанием билд-процесса, указанием последовательности команд и маркерами неуспешного выполнения каждого этапа, и пришлось самому, но кроить CI/CD — это не в обратную сторону. В обратную сторону — это, например, добавить реализацию функции приложения "потому что разработчик в отпуске". И да, вчера на Python, сегодня на Go.
А там, в коде, был "ужасный хак", который команде разработчиков был известен, а девопсу сходу не понятен:
int itemsCount = getItemsCount();
int chunkSize = getChunkSize();
int chunksCount = (itemsCount + chunkSize - 1) / chunkSize;Девопс заменяет на стандартное деление через double, и вот уже имеем регрессию, а разработчики как довольны!
PS. Глянул на хахашечку, что-то не похоже на исключительно высокие ставки оплаты девопсов. У разработчиков такие же.
Согласен, тут не в обратную сторону. Но у меня были и примеры в обратную сторону, разрабы решили использовать для работы с S3 curl и жаловались на скорость и производительность, а я сделал MR в котором предложил использовать библиотеку boto3. Это решило проблему.
Ну и еще один момент - GitLab CI не самая сложная история, у меня друг, плюсовый разраб, разобрался за рабочий день и сделал пайплайн для своего пет проджекта. Да он каких-то нюансов не знает и приходит ко мне за ответом на некоторые вопросы. Но мой товарищ программист старой школы, он способен дотащить свой код до прода и он регулярно мне говорит, что не понимает зачем я нужен и почему нашей когорте столько платят. Так что я крайне благодарен младому племени разрабов, которые готовы писать только код и только код, им глубоко фиолетово как это будет работать в "проде" и пусть этим занимается кто-то другой. Я понимаю, что я точно не пропаду и на свой хлеб с маслом всегда заработаю.
Ну и по итогу хочется сказать, что GitLab CI в освоении на порядки проще любого языка программирования.
Про boto3: ты оказал разработчикам медвежью услугу. Вполне возможно, они намеренно не использовали boto3, потому что:
кривожопые амазоновцы решили сделать, как у взрослых пацанов в WSDL, но по религиозным причинам выкатились на JSON, в итоге у них в библиотеке интерфейса нет (он приезжает потом с сервера при инициализации сервиса в схеме), автодополнения тоже нет
особым мазохизмом становится ловить исключения в boto3, потому что классы исключений приезжают тоже потом, вместе со схемой, то есть, ты не можешь просто написать try/except на конкретный тип, ведь этот тип неоткуда импортировать на этапе компиляции скрипта
Вполне вероятно, твой следующий шаг будет показать разработчикам awswrangler — это уже обёртка над boto3, тоже от амазона, но с человеческим лицом, готовыми интерфейсами и, более того, которая не просит кидать в параметры лютую дичь, за которой каждый раз надо лезть в справку, в которой оно ещё не всегда в одном месте описано. У него, правда, есть один недостаток: он покрывает лишь самые распиаренные сервисы AWS, такие, как S3/Parquet, Lambda, DynamoDB. Что-то не столь часто используемое там просто отсутствует.
Ну что, всё ещё "инженер разбирается во всём"?
Так это уже тренд. За зп в 200к нужен мидл разраб, который будет настраивать докер, кафку, кубер, писать СИ/СД, писать автотесты и ещё желательно сам с заказчиками общаться.
Зачем в этой схеме нужен кабанчик непонятно.
Я думаю, Денис имел ввиду не "почини принтер", к такому те кто несут ответственность за принтеры сами не подпустят. А вот умение включить принтер и настроить параметры печати самому будут полезны.
В терминах того же докера это скачать десктопный клиент и компоуз файл, проставить там настройки и запустить.
А писать скрипты и обслуживать СИ/СД с ним это уже починка принтера.
к такому те кто несут ответственность за принтеры сами не подпустят
Если есть выделенный девопс, то уверен, что он тоже будет не сильно рад, если разработчики начнут сами писать скрипты для CI/CD
Ну не знаю, не знаю... На мой взгляд, в базе работу CI на своём продукте разработчикам знать весьма желательно (кроме знания что используется Gitlab, а не скажем Jenkins). Не всегда бывает возможность у инженера DevOps прибежать и сделать фикс. А так перезапустить пайп с другими переменными, ввести их через вебчик, просто перезапустить упавшую джобу (всякое бывает знаете ли) и так далее, уметь делать весьма желательно.
Некоторое время назад была такая тенденция, девопсы не нужны, мы всё скинем на девелоперов, дадим им доступ к gitlab_ci.yaml, и будет всё прекрасно.
На деле оказалось, что девелоперы это всё видали в парке, и стали разбегаться туда, где их такой фигней не нагружают, спрашивать сразу при устройствие, не прийдётся ли, часом, делать девопсовые таски, и отказываться от заманчивых офферов идти туда, где прийдётся.
А ещё оказалось, что те девелоперы, которые не разбежались, не обладают этой квалификацией и не горят её получать. И всё время тут не работает, там не авторизовано, здесьу упало, и каждая простейшая задача требует сто лет, чтобы разобраться, как же оно там должно всё-таки быть, а это другая команда должна делать, пусть доступ нам дадут, нет? А как? А кто? Я всё перепробовал, оно не работает точно-точно, это на их стороне.
Короче, где-то через пару лет оказалось, что это не работает.
Потому же, почему менеджер по продажам не может ещё и бухгалтерию вести, а бухгалтер не может заодно и маркетингом заниматься.
На деле оказалось, что девелоперы это всё видали в парке, и стали разбегаться туда, где их такой фигней не нагружают, спрашивать сразу при устройствие, не прийдётся ли, часом, делать девопсовые таски, и отказываться от заманчивых офферов идти туда, где прийдётся.
Для меня если я услышу что пайлайнами занимается отдельный девопс не из моей команды то это будет жирный минус вакансии. Я насмотрелся когда для простых изменений в моем пайлайне нужны тикеты, ожидание месяцами для изменения 1 строчки, а как мне удобно пайплайны запускать решают люди слоабо связанные с проектом.
Короче, где-то через пару лет оказалось, что это не работает.
Из того что я вижу -работает лучше чем с отдельными админами/девопсами.
Я девопс прямо в той же команде, то есть не отдельная команда, а отдельный человек, никакие супер-бюрократические процедуры не нужны, плюс я в курсе, как проект работает, и кто нам денег платит и за что. Это хорошо помогает расставить приоритеты.
Самому, конечно, тоже можно, я всегда за, всегда спрашиваю, вам рыбу или удочку, если спрашивают. Можно не спрашивать и самим делать тоже сколько влезет, доступы есть, желания обычно нет :)
Знаком и с Gitlab pipelines и с Github Actions, можете описать, чем лично вас привлекает именно Gitlab? Потому что, на мой взгляд у них много минусов
Гитлаб имеет CE версию, в которой из коробки есть все, что нужно среднего размера компании, это ничего не стоит и относительно легко администрируется. При этом actions - это зачастую сомнительного качества код на js, оно быстро все становится дорогим, а суть логики пайплайнов не проще, чем в гитлабе.
Я её не видел, читал документацию, часто попадалось Ultimate версия. Но не нашёл ничего особенного.
Мне тут захотелось включить timestamp для каждой строчки лога, оказывается у Gitlab есть такой issue, ему уже несколько лет и там гитдабовцы всеми силами пытаются рассказать, как у них нет времени. Ага, timestamp-ом дополнить строчку.
Я честно говоря не встречал в Actions от Docker и других именитых производителей какие-то косяки. И там не обязательно на JS писать.
Что конкретно становится дорогим. Вот у меня 30_000 часов в месяц для Actions. Я плачу 4$ в месяц за это. Ия честно пытался истратить это время. Но мне удалось лишь на 15%. Ну и ещё, можно поставить себе runner, тогда за actions платить не надо.
Я в Actions от гитхаба встречал столько косяков, что не перечесть - начиная от отсутствия нужных версий и их неактуальности, заканчивая неработоспособностью чуть-чуть нестандартных вещей, типа action, который устанавливает VPN соединение для того, чтобы деплоить внутрь контура компании. У нас просто с вами разный экспириенс. Ну и в целом все Actions - это как набор плагинов, написанный совершенно разными людьми, с совершенно разными подходами. Как результат - вам постоянно надо изучать какие-то сторонние полурабочие вещи и дописывать их.
С гитлабом ситуация выглядит не так - документация консистентная, описывает вполне конкретные вещи, в ней все предельно понятно и прямолинейно. Есть ли ограничения - конечно есть, но они есть везде. Мне нравится то, что косяков мало и все в одном месте и единообразно.
Что конкретно становится дорогим. Я не знаю, как активно вы пишете - но у меня, например, только ansible ролей около сотни лично написанных. Под каждое изменение этих ролей запускаются тесты. Я из бесплатного лимита выходил меньше, чем за неделю - и когда Travis CI был, и когда Actions появились. 4$ там никак не получалось у меня.
Спасибо, я понял вашу позицию, но более лёгкой работы с GL не принесло.
Чисто по тому, что вы написали. Внутрь VPN-а если деплоить, то вас вполне устроит self-hosted runner. К тому же, не придётся платить за минуты: https://github.com/actions/runner
Мы какие-то разные компоненты видели, вот, например с официальной доки Docker-а (на гитхабе тоже в доке есть офиц туториал)
https://docs.docker.com/build/ci/github-actions/
Виноват, 3000 минут. И да, я смог истрачивать лишь 15%. Это двое суток беспрерывной работы. Самые тяжёлые мои сборки длились по минут 40 × 5. Т.е. в 5 различных платформах 10 раз в сутки
GitLab имеет много фишек на борту, которых нет у GitHub. Я рассматриваю GitLab исключительно как self-host решение для разворачивания на своей инфраструктуре, и в этом, насколько я знаю, GitLab намного сильнее. Тут тебе и CICD интегрированный, и планирование Scrum с эпиками, спринтами и т.д.
Github Actions как по мне лучшее что сделал гитхаб для разработчиков, при этом бесплатно.
При этом, как по-мне, Gitlab CICD все равно выигрывает по всем фронтам)
Гитхаб побеждает именно в плане доступности.
Бесплатно, открыто, удобный интерфейс.
Гит как раз удобен тем что можно хоть с телефона с сайта поправить и акшен сам запустит тесты и все пересоберет наглядно
.
Для закрытых систем лично я предпочитаю строить комплексно, начиная от хуков гита и заканчивая отдельными скриптами. Прям полная автоматизация "автерпуш" нужна в очень релких и спецефичных ситуациях.
Насчет бесплатности и удобного интерфейса я б поспорил) Тот же гитлаб без проблем предоставляет те же фичи бесплатно, а тот же интерфейс гитлаба, ИМХО, но перегружен и не интуитивен
А как насчёт CLI? Например, очень удобно GA управлять из консоли, скачивать логи или в реальном времени видеть лог, запускать, отменять, удалять, настраивать, etc.
Я не нашёл такой инструмент у Gitlab
У гитлаба есть свой API, который имеет обширный функционал и отлично интегрируется в самые популярыне IDE) И так взаимодействовать с репозиторием можно спокойно в UI самой IDE без CLI)
Ну серьёзно, я просто хочу знать, где лучше?
А на фоне гитлабовской отмены фич (в новых версиях нельзя будет делать отладку пайплайнов и тп), мне как-то даже странно, что вы защищаете.
Кстати, а каков ваш опыт работы с GA?
Скрипт CI пишется на YAML. .gitlab-ci.yml - это единственный файл, который лежит непосредственно в корне проекта. В любых других папках GitLab его просто не прочитает, соответственно пайплайн работать не будет.
Небольшое дополнение - файлик может быть и не в этом репозитории. Иногда такое требуется из соображений безопасности
Полезная статья
Скрипт CI пишется на YAML. .gitlab-ci.yml - это единственный файл, который лежит непосредственно в корне проекта.В любых других папках GitLab его просто не прочитает, соответственно пайплайн работать не будет.
Даже читать дальше не стал. Уважаемый автор Вы хоть и большой молодец, но учиться, учиться и еще раз учиться. Можете почитать, например, про include и для чего он используется, вот небольшая выдержка из учебных материалов:
include:
- local: 'backend/.gitlab-ci.yml'
- local: 'frontend/.gitlab-ci.yml'
- template: Security/SAST.gitlab-ci.yml
Вы в универе сразу квантовую физику учили или сначала школьную повторяли на продвинутом уровне? То то и оно. Имхо для уровня разработчика самое оно, ему нужны базовые вещи там возможно какой то сайд пайплайнчик сделать не для основного проекта, например какой то вспомогательный инструмент может даже не для прода, поправить что то несложное. А на что то серьезное (если оно когда то понадобится) специалисты будут привлечены.
Так что автор все по делу пишет, а вы, извините, ерунду
Очевидно, что имеется в виду стартовая точка.
А приведенный кусок откуда? Не из .gitlab-ci.yml ли?
Считается, что построение CI/CD - задача для DevOps. <...> Но часто с докручиванием отдельных этапов процесса сталкиваются и разработчики.
Типичная ошибка в определении DevOps. Отдельных людей, которые занимаются DevOps быть не должно, если они есть, то они зовутся SRE. А DevOps -- это, как раз, методология, в которой задействованы все слены команды, и, в первую очередь, разработчики.
Не статья, а скорее набор заметок. Больше вопросов, чем полезных материалов. Если я буду публиковать такие и выдавать за статьи, меня забанят)
Но все равно спасибо. Одну новую фичу я вычитал.
А заголовок - кликбейт.
Настройка CI/CD для самых маленьких разработчиков