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