company_banner

CI/CD — обещания и реальность

Автор оригинала: Charity Majors
  • Перевод


Мы говорим «CI/CD» и подразумеваем непрерывную интеграцию. Никто не имеет в виду (и не практикует) непрерывный деплоймент. Вообще никогда. О нем все забыли. Пора это изменить.


Поучительная история


Один большой и страшный пиратский корабль наводил ужас на всю округу, хоть и подтекал немножко. После шторма или битвы пиратам нередко приходилось откачивать воду с нижних палуб.


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


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


Мораль истории такова: устраняйте не симптомы, а причину.


Что подводит нас к разговору о CI/CD?


CI/CD (непрерывная интеграция и доставка, или деплоймент) — это часть нашей жизни. Мы ходим на конференции по CI/CD, пишем статьи о CI/CD, ведем блоги о CI/CD, указываем CI/CD на странице LinkedIn. Никто даже не спорит, надо оно нам или нет. Мы все одинаково обожаем CI/CD. Так ведь?


Вот только… мы говорим «CI/CD» и подразумеваем непрерывную интеграцию. Никто не имеет в виду (и не практикует) непрерывный деплоймент. О нем все забыли.


Нет, это замечательно, что мы так поднаторели в непрерывной интеграции за последние лет десять. Но этого же мало. Это даже не половина. Можно подумать, цель непрерывной интеграции — наслаждаться своим красивым синтаксисом и логикой. Хотя это приятный бонус, кто же спорит. По факту же CI — это просто подготовка к следующему этапу — непрерывной доставке. Потому что вообще-то в этом вся суть.


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


Что это вообще такое — CI/CD?


Отличный вопрос. Отвечу с удовольствием. CI/CD — это процесс и методология, цель которой — убедиться, что весь код, вливаемый в главную ветку, можно в любое время протестировать и задеплоить. Автоматически. После каждого дифа.


Цель конвейера CI/CD — ускорить внедрение изменений в программах настолько, чтобы мы не успевали выпасть из контекста и забыть, что это были за изменения.


Если любой в вашей команде может отправить изменения в главную ветвь, точно зная, что через 15 минут они будут протестированы и развернуты в продакшене без человеческого вмешательства, — наши поздравления! Вы используете CI/CD.


Жаль, что редкая команда может похвастаться этим. Хотя это основы гигиены разработки.


Гибельный водоворот разработки


Представьте, что между разработкой и доставкой ваш код лежит в чашке Петри при комнатной температуре и обрастает вредными бактериями. Чем дольше лежит, тем крупнее дифы и медленнее ревью. Приходится ковыряться в этих монстрах и всматриваться в контекст при переходе с написания кода на ревью и обратно.


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


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


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


Раз все имеющиеся разработчики заняты, нужно нанять много новых и потратить еще больше усилий на их координацию. Скоро вам понадобятся отдельные должности — SRE, Ops, QA, билд-инженер, — чтобы героически бороться с каждым симптомом по отдельности. Для этой оравы нужно будет больше менеджеров и так далее. Вуаля! Получаем огромную, дорогую и неповоротливую компанию.


Все становится еще медленнее, еще труднее, еще запутаннее. Нужно больше ресурсов, чтобы управлять этой навороченной системой и бороться с побочными эффектами, которые только усугубляют ситуацию. Нас затягивает в гибельный водоворот разработки. Есть и другой путь! Мы можем изначально делать все возможное, чтобы сократить интервал между написанием строки кода и ее полноценным деплойментом в продакшене. Это должно стать нашей навязчивой идеей. Давайте автоматизируем этот интервал, будем отслеживать его, потратим драгоценные ресурсы на его сокращение.


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


Каким должен быть интервал? В идеале — 15 минут. Максимум час. Предсказуемость важна не меньше продолжительности, поэтому человек тут будет только мешать. Если сейчас вам требуется 15 дней, а не минут, не отчаивайтесь. Любые усилия по сокращению интервала обязательно окупятся. Любые!


Вижу, вы сомневаетесь. Моя команда, мол, такое не осилит, здесь вам не Facebook и не Google.


Вы идете сложным путем


Вы, наверное, удивитесь, но непрерывный деплоймент — это самый простой способ писать, поставлять и выполнять код в продакшене. Звучит нелогично: делать много маленьких изменений быстро бесконечно проще, чем несколько больших изменений медленно.


Смотрите сами. Какой баг легче найти, понять, воспроизвести и исправить: баг в коде, который вы сами написали буквально только что, или баг в коде, который кто-то другой написал в прошлом году?


Как это вообще можно сравнивать? Пока код еще свеж в памяти, мы четко видим проблему и ее решение.


В процессе написания кода позаботьтесь о своем будущем «я», которому через полчаса придется разбираться, получилось задуманное или нет. Итак, вы пишете код, отправляете его в главную ветку, ждете несколько минут и смотрите в продакшен. Все идет как надо? Или тут что-то не то?


В таком ритме разработчики обычно находят больше 80% всех багов сразу — пока ничего еще не забылось и знаешь, на что смотреть. Если что-то пошло не так, можно тут же слепить еще один диф.


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


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


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


Задача номер 1 для технических руководителей в 2021 году


Почему мало кто пытается наладить непрерывную доставку? Для меня это загадка. Ведь у быстрого исполнения и короткого цикла обратной связи очень много преимуществ, о которых все прекрасно знают. Но, кажется, я начинаю понимать.


Создается впечатление, что это не техническая задача, а вопрос персонала, проблема управленцев. Руководители привыкли решать такие проблемы своими инструментами — нанимая больше сотрудников.


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


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


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


Вам бы понравилось, если бы ваши специалисты всегда вспоминали вас как человека, который изменил их мышление и подход к разработке, и были благодарны вам за то, что помогли им выйти на новый уровень? Все зависит от вас.


Не надо быть гением, чтобы раскрыть весь потенциал CI/CD. Честное слово. Надо просто приложить чуть больше усилий к тому, чтобы наладить этот процесс. Хорошие специалисты вырастают в хороших командах.


При использовании непрерывной доставки разработчики несут всю ответственность за свой код в продакшене. Но это не единственное преимущество. У вас появляются полезные привычки — писать маленькие дифы, быстро ревьюить код, воплощать свои изначальные намерения, использовать переключатели функций, разделять деплои и релизы и т. д.


Можно целыми днями цепляться к разработчикам и требовать, чтобы они подчищали код и следовали лучшим методам по отдельности, а можно приложить все усилия, чтобы сократить цикл обратной связи, и тогда все встанет на свои места само по себе.


Сложно ли это? Еще как. Надеюсь, мне удалось вас убедить, что оно того стоит. Это изменит вашу жизнь. Это шаг к социотехническим системам будущего. Чем больше команд его сделают, тем лучше. А какой у вас план по CI/CD на 2021 год?


Узнать больше о CI/CD и получить практику создания пайплайнов можно на курсе «Слёрма» «CI/CD на примере Gitlab CI.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

А как у вас работает CI/CD сейчас?

  • 34,2%Автоматический только CI, а доставка кода куда-либо – только по нажатию кнопки человеком53
  • 25,8%Реализован автоматический CI для нужных веток и CD в dev/staging/pre-prod окружение без участия людей40
  • 18,7%Полный автомат – CI/CD в продакшен29
  • 21,3%Тестируем у себя локально, деплоим вручную :)33
Southbridge
Обеспечиваем стабильную работу highload-проектов

Комментарии 42

    +3
    Итак, вы пишете код, отправляете его в главную ветку, ждете несколько минут и смотрите в продакшен. Все идет как надо? Или тут что-то не то?

    Складывается впечатление что вы деплоите в продакшен приложение для заказа пиццы… Предположим что в результате бага в коде у вас при очередном деплое произошло необратимое повреждение данных в продакшен базе… А такое легко может случится т.к. автоматические тесты часто не могут проверить все возможные случаи или не имеют ровно такие же данные как на продакшен базе. Сколько времени займет автоматический откат таких изменений? Как много данных будет при этом потеряно? Вы точно хотите жить в ситуации когда в произвольный момент времени у вас может сложится прод? И при этом для каждой фичи на 1 строчку полезного кода вам приходится писать 10-100 строк тестового кода для того чтобы гарантировать стабильность прода.

      +3
      При прочтении были весьма схожие мысли.

      Понятно, что такой подход весьма пригоден для какой-то stateless логики, для числодробилок всяких, без кучи внешних зависимостей.
      Очевидно, что можно обложится кучей автотестов (включая интеграцинные), гейтов, аппрувалов и прочих предохранителей.
      И, возможно, такой подход будет работать даже для сложных систем, если вы настроили сине-зеленый деплой, canary релизы, контейнеризацию и вот это вот все…

      Но это все трудозатраты, и причем немалые. На проектирование всего этого добра, на автотесты (которые надо будет поддерживать наравне с функциональным кодом), на настройку и отладку пайплайнов, на перестройку рабочих процессов в команде (если это первый опыт), на рефакторинг существующего решения, дабы подстроить его под CD подход (вплоть до изменения архитектуры а-ля «давайте перепишем все на микросервисы»).

      Вопрос всегда в эффективности/оправданности всех этих телодвижений.
      Оправданны ли все эти трудозатраты для продукта с жизненным циклом в год-два?
      Подходит ли весь этот аджайл для софта выполняющего критичные функции (захотели бы вы чтобы изменения приезжали таким образом в вашу ОС например?)

      В общем, статья попахивает популизмом. Но за перевод спасибо.
        0
        Вопрос только в том, как ручной деплой раз в месяц повышает надежность и снижает риски относительно нормально настроенного автодеплоя (в пайплайн которого хорошо бы включать и интеграционные и регрешн и енд-то-енд и нагрузочные тесты)?
        По мне ответ: никак. Просто собирается вся команда в день Х и, судорожно сглатывая, нажимает на кнопку. А результат одинаковый: либо упадет, либо нет.
          0

          Разница как минимум в том что команда судорожно сглатывает только в день Х, а в случае CD ей приходится это делать каждый час при каждом пуше.


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


          Из моей практики наиболее оптимальная схема когда CD работает автоматически на всех окружениях кроме прода, а прод допустим планово обновляется раз в 2 недели (и может внепланово обновляться в случае критических проблем)

            –1
            в отличии например от автоматического деплоя который может совершенно внезапно решить обновить контейнера в кубернетесе именно в момент пиковой нагрузки

            У нас с Вами разные представления об автоматическом деплое. У меня в голове автоматический деплой настроен правильно и обкатан и потому не может выполнять никаких «внезапных» действий.
              0
              У меня в голове автоматический деплой настроен правильно и обкатан

              А могли бы Вы вкратце описать свой проект и инфраструктуру деплоя? А также сколько времени и средств ушло на настройку и обкатку правильного деплоя? И примерно сколько средств уходит на его поддержание в правильном состоянии?

                +1
                Я из тех, кто «Тестируем у себя локально, деплоим вручную»… на тесты время не тратим совсем )

                недавно надо было в базе поменять модель — в mongo сильно поменялась структура одного Document-а… в итоге надо было атомарно поменять модель в одном микросервисе + DTO-шки на десятке других микросервисов на нескольких серверах и сами микросервисы проверить… сел ночью, аккуратно руками сделал, всё протестил. Интересно как фанбои CICD бы выкручивались )
          0

          Я все же думаю имелось в виду какой-то тестовый "прод".
          Либо только из stable ветки.

            0
            Вам стоит почитать про trunk based development, там есть ответы на некоторые ваши вопросы/опасения
            +1

            В названии CI/CD явно указана цель методологии — continuous. Вы поправляете опечатку, пушаете в гит, и запускается CI-джоба/пайплайн. После чего она тянется, и тянется, и тянется, и оно continue, continue, continue… вы срезаете углы с целью получить результат хотя бы через пол-часа, но это приводит к взрыву сложности в сопровождении и вы отказываетесь от этого. А потом к вам приходят с ещё одним важным багом, который можно обнаружить, только если выполнить сценарий целиком, и вы добавляете ещё одну continue к своему continue, и надеетесь, что CI будет успевать отработать за ночь хотя бы раз, но к вам приходят с ещё одним сценарием....


            Чтобы иметь возможность работать хоть как-то вы инвестируете в ресурсы, чтобы иметь возможность запускать два процесса в параллель. Но этого мало, и скоро у вас целая ферма серверов, которые непрерывно continue.


            А если у вас не так, то
            а) Вы не проверяете свой проект полностью (часть либо на аутсорсе у других компаний, либо вообще "мы про это не думаем")
            б) У вас невоспроизводимая среда, либо среда зависящая от золотых артефактов.


            А ещё вы, возможно, фулл-стек-божий-одуванчик, который думает, что JS+node — это и есть весь стек. А кто именно держит bgp с аплинками вы как-то и не думали.

              0
              А кто именно держит bgp с аплинками вы как-то и не думали.
              вот сейчас батя с подстанции придет со смены — расскажет, кто держит ваши bgp с аплинками :)

              Но, если серьезно, то ИМХО у каждого должен быть свой горизонт видения, и только если мы начинаем говорить о техлидах-синьорах, тогда нужно вспоминать, что вообще-то никто не работает в вакууме и каждый стоит на плечах инфраструктуры.

              А по теме CI\CD — то лично я считаю, что надо начинать с того, чтобы node watch (и прочие аналоги) выдавали Ok или Fail через секунды после нажатия на Ctrl-S (а не через 5 минут или больше, как иногда бывает), и тогда можно уже параллелить билды с деплоями.
                +1

                Я про другое говорю. Одна из проблем в CI/CD — невероятное замедление feedback loop, неизбежное по мере увеличения покрытия тестами. Чем дольше этот loop, тем хуже процесс разработки. Чем дольше этот loop, тем лучше протестирован код.

                  0
                  это все от дешевизны программистов и результатов их труда. Как только программисты\результат становятся дорогими — так и тесты параллелятся и инстансы для этого оплачиваются.
                    0

                    Аренда сервера — 100 баксов в месяц. Хорошего сервера. Аренда программиста — over 5000. Очевидно, сервера дешевле.


                    Однако, не все процессы параллелятся. Более того, появление паралеллизации, совпадающее с добавлением всякого рода сценариев, часто лишь увеличивает время выполнения (за счёт wait for slowest и общей части).


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

                      0
                      Аренда сервера — 100 баксов в месяц.
                      вот это вы наверно не про банкинг сейчас и не про медицину :)
                      В геймдеве когда поработал и то — была куча усилий по переводу билда+тестов на внешние сервера… (потому что цена риска — это как минимум зп менеджера, который это разрешил)

                      Более того, появление паралеллизации, совпадающее с добавлением всякого рода сценариев, часто лишь увеличивает время выполнения (за счёт wait for slowest и общей части).
                      эээ… если у вас есть два теста, один самый медленный, а второй — побыстрее, то нет экономии времени от запуска их параллельно??? (я уж молчу, если там внутри бегает сотня тестов)
                        0

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


                        Грубо говоря, был CI, фигачил час. Сделали второй сервер, стало можно пускать два сценария. Один сценарий фигачит 58 минут, второй 1 час 20 минут. Итого — CI фигачит час двадцать вместо часа.


                        Это как с дополнительными полосами на хайвее. Если уже пробка, то добавив полос, станет только хуже.

                          0
                          а, если добавить очень долгий тест, то он будет замедлять — это понятно.
                          Но согласитесь, что без распараллеливания у вас был бы сценарий на 2 часа 18 минут вместо 1 часа 20 минут.
                          (ну или сборка была бы с меньшим покрытием тестами)
                            0

                            Без параллеливания никто бы не согласился на ещё +1.2 часа. В этом и драма CI. А когда есть горизонтальное масштабирование, то "почему бы и нет".


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


                            См про дополнительные полосы хайвеев.

                              0
                              у нас еще есть разделение на smoke и прочие тесты — первые гарантированно отрабатывают за минуту и только этот набор запускают перед перед тем как дать «зеленый свет». В параллель им запускаются все остальные медленные тесты — но они работают автономно и ничего не блокируют (и не замедляют).
                                0

                                А вот я бы почитал, обстоятельно, как вы с такими живёте. Мысль сделать часть тестов асинхронными у меня есть, но тут же как — если в CI всё зелёнькое, можно мержить/выкатывать. А если там на заднем плане Длинный Унылый Сценарий всё обсыпал и вопит, то к этому времени код уже на продакшене быть может.

                                  0
                                  не, в продакшен оно идет только после выката нескольких фич на препродакшен и показа демо-версии клиенту(-ам).
                                  А автоматические тесты — это для погромистов, когда свой код уже написал, а ревьювер его еще не посмотрел. К тому времени как досмотрит — добегают и «длинные сценарии».
                                    0

                                    У вас CD тогда нет.


                                    … В целом, за всю мою карьеру, я один раз сделал идеальный CI/CD, который уже примерно 5 лет работает с минимальными изменениями, когда робот "всё сам" (включая апдейты из апстрима и публикацию в продакшен). Но там специальный случай и готовность ждать часами.

                                      0
                                      У вас CD тогда нет.

                                      на препродакшен же.

                                      PS: прямо в продакшен никто не разрешит все равно — банкинг, сэр!
                                        0

                                        Ну, это не CD.


                                        И да, чаще всего есть Глубокие Причины, почему не CD. Я ж говорю, за всю свою жизнь у меня один раз получилось сделать "тесты прошло — годится на продакшен не глядя". И то, в очень специальном случае.

                                          0
                                          ненене, полностью «бесчеловечные технологии» — это все-таки тоже нехорошо. ИМХО должен быть ответственный человек (как в традиционном производстве — в виде таблички «Ответственный за Х — ФИО» ).
                                            0

                                            Есть команда, которая отвечает за этого робота. Если приходят (неожиданные) баги или странные фичи-реквесты, то они начинаются с красных тестов в CI, а заканчиваются зелёными. Как только тесты зелёные, происходит CD, без участия человеков. В силу того, что основная движущая сила изменений — это апстрим (не считая мелких багфиксов с нашей строны), CD работает по вторникам. Автоматически. (Ради этого и писалось).

                                              0
                                              ну, мое недоверие растет из того, что я не верю тестам :)
                                              (уж сколько раз ловил на том, что в коде Sum(a,b){return 5}, а в тестах assert(Sum(1,1)==5) )

                                              К тому же команда, которая отвечает за процесс CD, все-таки не должна отвечать за чужой код и тесты.
                                                0

                                                Апстрим код всё равно тестировать надо (smoke тесты, хотя бы). Проект, про который я говорю — это обновление image'ей для cloud'а (они собираются из пакетов с нуля), чтобы они были актуальными, но при этом работали. Там огромная тестовая база с кучей неочевидных тестов (после plug/unplug интерфейс должен получить dhcp каждый раз, а не только первый и т.д.).


                                                CD команда с тестами для "чужих" людей это нормально. Называются "приёмочные тесты".

                    0

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

                      0

                      И, разумеется, за вычетом линтеров, всё самое хорошее и важное будет прилетать уже в конце pipeline'а. Закон Мёрфи для CI/CD, всё такое.

                        +2

                        C хорошим CI/CD вы гарантированно будете получать обратную связь не медленнее, чем без него. А уж если у вас самые ценные тесты — самые длинные, то это вопрос к тому, как вы тестируете, а не к процессу доставки.

                          0

                          И это правда. Хотя локальный запуск обычно всё-таки быстрее. Но это и есть проклятье CI — чем больше тестируешь, тем дольше ждать результаты.

                            0

                            Да при чем тут CI? Вы можете автоматически тестировать и без CI. И CI (даже с CD) может быть без автоматических, но с ручными тестами. CI — это процесс, а не какой-то фреймворк.

                +1
                Хммм.
                В статье речь только про SaaS, я так понимаю.
                В мире On-Premise правила игры немного другие.

                Есть такая контора — GitLab (иронично упомянутая в статье), которая активно пытается быть лидером в CI/CD.
                Релизные циклы — раз в месяц, 22го числа.

                А знаете, что происходит в течение недели после их релиза?
                Выход патчей )
                Баннер «Update ASAP» в админке self-hosted гитлаба до конца месяца — это норма.

                Ну и где теперь ваш CI/CD, а?
                  0
                  Автор пишет
                  В целом разработчики понимают ценность непрерывной доставки. Многие из них мечтают работать в таком режиме.
                  А потом удивляется, откуда берется мнение про «херак-херак и в продакшен».
                  Что-то не так с логикой, или фаза «выпустить продукт (пофиг какого качества) первыми» из сомнительной, но иногда, к сожалению, работающей практики переросла в фазу «теперь всегда так будет, ибо это хорошо»?
                    0

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


                    Мое мнение: если разработка прошивок в 2021 идет без тестов и CI, то это шуточная разработка. Скорее всего, собралось куча джунов с открытым дебаггером и делают вид что работают.

                      +1
                      CI собирает их, прогоняет тесты, прогоняет статический анализатор и публикует готовую прошивку для производства.

                      И вот именно эта прошивка будет залита на следующее реальное устройство, собранное производством через 5 минут? Потому что если нет — то, по мнению автора, это нифига не СD
                        –1

                        Да, CD нет, но думаю это решить смогут (но уже без меня). Как раз все это затевалось ради того, чтобы производство само могло подтягивать свежую версию прошивки, без перекидывания хексов в телеграме.


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

                      +1
                      Если CI — это полностью техническая часть и она, безусловно, должна быть, то CD — это ещё и маркетинговая, продажная, рекламная и другие части. Мы не релизим новую версию мгновенно не потому, что не можем, а потому, что продажники обещали одним клиентам одно, другим — другое, кому-то раньше, кому-то позже. Что-то написанное вообще никогда не попадёт в релиз по финансовым причинам, что-то будет релизнуто мгновенно.

                      Как можно автоматически релизить всё? Это предполагает, что маркетинга и продажников у вас в компании нет вообще и на рынок вам плевать.
                        +1

                        Автор статьи: "Никто не имеет в виду (и не практикует) непрерывный деплоймент. Вообще никогда. О нем все забыли."


                        Читатели статьи:



                        P.S. Это кстати отлично показывает то, что необходимо приводить пруфы к таким заявлениям. Не "очевидно, что никто этим не пользуется", а "согласно опросам проведенными тем-то агенством 75% команд не знают что такое CI/CD и не используют его".


                        Такие нюансы показывают действительно хорошего автора)

                          0

                          Очень сильно подозреваю, что многие ответившие "Полный автомат" на самом деле не понимают о чём речь и никакого полного автомата в продакшен у них нет.


                          Здесь же, на Хабре, есть куча статей "как у нас устроен CI", а вот "как у нас устроен CD" — по пальцам пересчитать.


                          Ну и комменты к этой статье это подтверждают.

                          0
                          Согласен. В компании Amazon уже много лет применяется практика CD, и, на мой взгляд, весьма успешно.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое