Pull to refresh

Comments 8

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

От прочтения данной статьи возникло море вопрсов.

Идеологически CI базируется на следующих соглашениях:
часто (не менее 1 раза в день) «заливать» свой код в репозиторий
Зачем? Т.е. если я сегодня не залил изменения на сервер, то я поломал CI на предприятии? На мой взгляд важно не регулярно заливать, а регулярно производить сборку.
запускать private builds(процесс сборки, который выполняется с использованием исходного кода, в данный момент находящегося в
локальном репозитории разработчика)
не «заливать» неработающий код
Это возможно если весь инструментарий CI развернут на машине разработчика, иногда это неудобно — у разработчиков могут быть различные версии ПО (ОС) и т.п. Возможно более удобным решением может оказаться pre-tested commit.
следить за тем, чтобы все тесты и проверки проходили
Следить и что?
не выкачивать из репозитория сломанный код
Как? Как я узнаю, что среди изменений, которые были залиты другими разработчиками есть сломаных код? И если даже я это и узнаю, то как технически я уговорю свою систему контроля версий это сделать?

Скрипт сборки — это набор комманд, которые будут выполнены при запуске процесса интеграции. Чаще всего он выглядит как следующий набор шагов:
Компиляция (или статический анализ кода для интерпретируемых языков)
Для компилируемых языков статический анилиз тоже может быть успешно использован.
Разворачивание программного обеспечения
Могу ошибаться но это уже Continuous Deployment (если речь не идет о разворачивании приложения в Staging Environment для его тестирования).

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

На сколько надежна система
Не понял к чему этот раздел.

Решения:
доклады по CI и модульному тестированию
просветительская работа с каждым разработчиком
сотрудничество с QA департаментом
Не благоданое это дело…
изменение в процессе разработки, предполагающее обязательное написание тестов
Как именно вам этого удалось добиться?

Планы:
наладить процесс написания модульных тестов перед кодом, фактически переход на TDD
Ню-ню ;)…

Желаю удачи в дальнейшем внедрении и использовании!
Спасибо за комментарий, очень полезно и интересно узнать мнение других людей на этот счет.

Зачем? Т.е. если я сегодня не залил изменения на сервер, то я поломал 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, и некоторые его пункты на практике, особенно в больших проектах с легаси кодом и устоявшимися процессами разработки, применить достаточно тяжело.
Возможно речь идет о smoke тестах?

Речь скорее о unit тестах, которые как правило выполняются быстрее всех остальных типов тестов.
Решения:
•доклады по CI и модульному тестированию
•просветительская работа с каждым разработчиком
•сотрудничество с QA департаментом
•изменение в процессе разработки, предполагающее обязательное написание тестов


А есть ли измеренные результаты этих решений?
Если вас интересует на сколько улучшилось качество в «граммах», то, видимо таких цифр я Вам дать физически не смогу — не меряли. Могу как альтернативу сказать, что после того как при разработке нового модуля мы выполнили указанные мной шаги, у нас не было ниодного «мажорного» или «блокед» тикета, количество минорных до десятка, лид стал способен отвечать на вопросы менеджеров о готовности модуля к релизу, на вопросы QA отвечали зеленые билды, а если что-то было не совсем ясно с функционалом — разработчики сразу смотрели тесты испульзуя их в том числе и как документацию. Надеюсь ответил.
Only those users with full accounts are able to leave comments. Log in, please.