Comments 8
Статьи про CI это всегда интересно. Тема мало того что обширная, так еще и существует огромное количество способов практической реализации той или задачи. В таких статьях всегда можно увидеть, что люди используют чего не использую я.
От прочтения данной статьи возникло море вопрсов.
Желаю удачи в дальнейшем внедрении и использовании!
От прочтения данной статьи возникло море вопрсов.
Идеологически CI базируется на следующих соглашениях:Зачем? Т.е. если я сегодня не залил изменения на сервер, то я поломал CI на предприятии? На мой взгляд важно не регулярно заливать, а регулярно производить сборку.
часто (не менее 1 раза в день) «заливать» свой код в репозиторий
запускать private builds(процесс сборки, который выполняется с использованием исходного кода, в данный момент находящегося вЭто возможно если весь инструментарий CI развернут на машине разработчика, иногда это неудобно — у разработчиков могут быть различные версии ПО (ОС) и т.п. Возможно более удобным решением может оказаться pre-tested commit.
локальном репозитории разработчика)
не «заливать» неработающий код
следить за тем, чтобы все тесты и проверки проходилиСледить и что?
не выкачивать из репозитория сломанный кодКак? Как я узнаю, что среди изменений, которые были залиты другими разработчиками есть сломаных код? И если даже я это и узнаю, то как технически я уговорю свою систему контроля версий это сделать?
Скрипт сборки — это набор комманд, которые будут выполнены при запуске процесса интеграции. Чаще всего он выглядит как следующий набор шагов:Для компилируемых языков статический анилиз тоже может быть успешно использован.
Компиляция (или статический анализ кода для интерпретируемых языков)
Разворачивание программного обеспеченияМогу ошибаться но это уже Continuous Deployment (если речь не идет о разворачивании приложения в Staging Environment для его тестирования).
По написанию и запуску тестов также принят ряд соглашений:Зачем?
более быстрые тесты должны запускаться первыми
тесты должны быть разделены по категориямЗачем?
тесты должны выполняться без ошибок при повторном запускеНе думаю, что это имеет отношение к CI.
На сколько надежна системаНе понял к чему этот раздел.
Решения:Не благоданое это дело…
доклады по CI и модульному тестированию
просветительская работа с каждым разработчиком
сотрудничество с QA департаментом
изменение в процессе разработки, предполагающее обязательное написание тестовКак именно вам этого удалось добиться?
Планы:Ню-ню ;)…
наладить процесс написания модульных тестов перед кодом, фактически переход на TDD
Желаю удачи в дальнейшем внедрении и использовании!
Спасибо за комментарий, очень полезно и интересно узнать мнение других людей на этот счет.
Регулярный апдейт репозитория позволяет быстро узнавать когда и кто сломал билд, следовательно можно вовремя предпринять меры, до выпуска релиза. Часто бывает так, что разработчик комитит изменения локально, за 1-2 дня до релиза начинается всеобщий пуш в релизную ветку, получаем ошибки интеграции. Т.е. как я себе это вижу — постоянное заливание кода в удаленный репозиторий позволяет вовремя среагировать на ошибки, плюс очень дисциплинирует.
У нас в компании есть следующий подход. Как Вы и описали, можно развернуть часть инструментария CI (продукт состоит из многих модулей, следовательно — разные технологии и т.п.) локально, а можно «постучаться» к билд серверу, на котором уже есть все, кроме того модуля, над которым в данный момент работает разработчик.
Сломанный код, ломает билд (конечно, если есть тесты), билд, перед выкачиванием изменений из удаленного репозитория я просматриваю состояние последнего билда (я пользуюсь встроенной в IDE интеграцией с CI сервером). Если Ваш вопрос в том, как это делать автоматически, то я практически уверен, что можно написать хук для пула репозитория.
У CI есть одно положение «билд падает быстро». Суть в том, чтобы как можно быстрее узнать о том, что билд сломан, для того, чтобы не менее быстро его починить. Поэтому, тесты и выстраиваются в порядке того, сколько времени занимает их выполнение.
Для того, чтобы пояснить, что в данном контексте понимается под надежностью, как ее посчитать и почему надежность каждого компонента важна.
Спасибо большое еще раз, за фидбек, если понравиться — у статьи будет продолжение с более детальным описанием каждого процесса и конечно же примерами.
Зачем? Т.е. если я сегодня не залил изменения на сервер, то я поломал CI на предприятии? На мой взгляд важно не регулярно заливать, а регулярно производить сборку.
Регулярный апдейт репозитория позволяет быстро узнавать когда и кто сломал билд, следовательно можно вовремя предпринять меры, до выпуска релиза. Часто бывает так, что разработчик комитит изменения локально, за 1-2 дня до релиза начинается всеобщий пуш в релизную ветку, получаем ошибки интеграции. Т.е. как я себе это вижу — постоянное заливание кода в удаленный репозиторий позволяет вовремя среагировать на ошибки, плюс очень дисциплинирует.
Это возможно если весь инструментарий CI развернут на машине разработчика, иногда это неудобно — у разработчиков могут быть различные версии ПО (ОС) и т.п. Возможно более удобным решением может оказаться pre-tested commit.
У нас в компании есть следующий подход. Как Вы и описали, можно развернуть часть инструментария CI (продукт состоит из многих модулей, следовательно — разные технологии и т.п.) локально, а можно «постучаться» к билд серверу, на котором уже есть все, кроме того модуля, над которым в данный момент работает разработчик.
Следить и что?Возможно, я не совсем четко выразил свою мысль, имелось ввиду, что не стоит «забивать» на случаи, когда не проходят 1 или 2 теста из общего набора, это все равно «красный» билд.
Как? Как я узнаю, что среди изменений, которые были залиты другими разработчиками есть сломаных код? И если даже я это и узнаю, то как технически я уговорю свою систему контроля версий это сделать?
Сломанный код, ломает билд (конечно, если есть тесты), билд, перед выкачиванием изменений из удаленного репозитория я просматриваю состояние последнего билда (я пользуюсь встроенной в IDE интеграцией с CI сервером). Если Ваш вопрос в том, как это делать автоматически, то я практически уверен, что можно написать хук для пула репозитория.
Для компилируемых языков статический анилиз тоже может быть успешно использован.Мое упущение, под статическим анализом я в данном контексте имел ввиду т.н. «линтовщики».
Могу ошибаться но это уже Continuous Deployment (если речь не идет о разворачивании приложения в Staging Environment для его тестирования).Вы правы, здесь речь идет о Staging Environment.
По написанию и запуску тестов также принят ряд соглашений:
более быстрые тесты должны запускаться первыми
Зачем?
У CI есть одно положение «билд падает быстро». Суть в том, чтобы как можно быстрее узнать о том, что билд сломан, для того, чтобы не менее быстро его починить. Поэтому, тесты и выстраиваются в порядке того, сколько времени занимает их выполнение.
тесты должны быть разделены по категориямОпять таки, для того, чтобы быстрее понять, что билд сломан. Можно разделять по фичам, по модулям и так далее, и при сборке корректировать в каком порядке запускать тесты.
Зачем?
На сколько надежна система
Не понял к чему этот раздел.
Для того, чтобы пояснить, что в данном контексте понимается под надежностью, как ее посчитать и почему надежность каждого компонента важна.
Не благоданое это дело…Дело конечно кажется неблагодарным, но мне это приносит удовольствие :)
Как именно вам этого удалось добиться?Успешное сотрудничество на уровне менеджмента департамента принесло свои плоды, удалось показать и рассказать в чем же «профит» предлагаемых изменений.
Спасибо большое еще раз, за фидбек, если понравиться — у статьи будет продолжение с более детальным описанием каждого процесса и конечно же примерами.
часто (не менее 1 раза в день) «заливать» свой код в репозиторий
Регулярный апдейт репозитория позволяет быстро узнавать когда и кто сломал билдЯ согласен с тем, что после того, как разработчик полностью закончил работу над задачей («заимплементил фичу», «пофиксил багу» и т.п.), то эти изменения должны быть в кротчайшие сроки добавлены в репозиторий. Но дело в том, что работа над задачей может длиться более чем один день, с одной стороны, а с другой, может содержать не один, а несколько коммитов (некоторые из которых могут содержать нерабочий код, но о котором знает разработчик). Резюмирую: однозначно поддерживаю слово «регулярно», но остаюсь при своем мнении и считаю, что говорить «не менее 1 раза в день» не корректно.
Т.е. как я себе это вижу — постоянное заливание кода в удаленный репозиторий позволяет вовремя среагировать на ошибки, плюс очень дисциплинирует.
У нас в компании есть следующий подход. Как Вы и описали, можно развернуть часть инструментария CI (продукт состоит из многих модулей, следовательно — разные технологии и т.п.) локально, а можно «постучаться» к билд серверу, на котором уже есть все, кроме того модуля, над которым в данный момент работает разработчик.Я хотел обратить внимание, что возмножы ситуации, когда разработчик не сможет обнаружить проблему локально и «зальет» неработающий код. И на мой взгляд это очень сложно обеспечить выполнение требования: не «заливать» неработающий код.
У CI есть одно положение «билд падает быстро».Возможно речь идет о smoke тестах?
На мой взгляд раздел выпадает из общей нити повествования.Для того, чтобы пояснить, что в данном контексте понимается под надежностью, как ее посчитать и почему надежность каждого компонента важна.На сколько надежна системаНе понял к чему этот раздел.
Спасибо большое еще раз, за фидбек, если понравиться — у статьи будет продолжение с более детальным описанием каждого процесса и конечно же примерами.Пожалуйста, ознакомиться с чужим опытом это всегда интересно.
Тоже очень хотелось бы увидеть продолжение этой статьи.
В целом, я Вашу идею понял, конечно, описан именно идеальный процесс CI, и некоторые его пункты на практике, особенно в больших проектах с легаси кодом и устоявшимися процессами разработки, применить достаточно тяжело.
Речь скорее о unit тестах, которые как правило выполняются быстрее всех остальных типов тестов.
Возможно речь идет о smoke тестах?
Речь скорее о unit тестах, которые как правило выполняются быстрее всех остальных типов тестов.
Решения:
•доклады по CI и модульному тестированию
•просветительская работа с каждым разработчиком
•сотрудничество с QA департаментом
•изменение в процессе разработки, предполагающее обязательное написание тестов
А есть ли измеренные результаты этих решений?
Если вас интересует на сколько улучшилось качество в «граммах», то, видимо таких цифр я Вам дать физически не смогу — не меряли. Могу как альтернативу сказать, что после того как при разработке нового модуля мы выполнили указанные мной шаги, у нас не было ниодного «мажорного» или «блокед» тикета, количество минорных до десятка, лид стал способен отвечать на вопросы менеджеров о готовности модуля к релизу, на вопросы QA отвечали зеленые билды, а если что-то было не совсем ясно с функционалом — разработчики сразу смотрели тесты испульзуя их в том числе и как документацию. Надеюсь ответил.
Sign up to leave a comment.
Continuous Integration. Путь обеспечения надежности и доверия к системе