Существует одна фундаментальная проблема, связанная с Continuous Integration (CI), которая отлично отражена в вашем вопросе: практики CI сложно реализовать и защитить, потому что программное обеспечение CI-сервера не тривиально в настройке и не тривиально, чтобы ваши проекты работали и выполнялись через CI сервер. При этом становится трудно понять, где вообще выигрыш от использования КИ.
Прежде всего, CI - это понимание и качество. Хороший CI приближает вас к вашему проекту, дает правильную обратную связь по показателям качества, документации, соответствию стандартам кодирования и т. Д. Он должен предоставить вам инструменты для простой визуализации всего этого, и позволит вам сразу же распознавать и легко связать набор изменений с определенным снимком всех этих метрик проекта.
Это не просто запуск модульных тестов. Не за что! Что подводит меня к качеству. КИ охватывает ошибки, не избегает их и не выбрасывает. Что он делает, так это просто предоставляет вам инструмент для выявления ошибок на раннем этапе, а не позже. Таким образом, вы на самом деле не передаете ранее протестированный код на CI-сервер. Хотя вы должны стремиться к фиксации чистого и не битого кода, вы фактически используете сервер CI для автоматического запуска компоновщика интеграции через ваш код и позволяете ему оценить, все ли получилось правильно. Если это так, аккуратно! Если это не так, нет проблем - хорошие практики CI утверждают, что вашим следующим приоритетом должно быть просто исправить то, что было сломано. Который, на хорошем CI-сервере, должен быть легко указан для вас.
По мере увеличения размера команды интеграция каждого кода, естественно, становится все труднее. Задачей централизованного CI-сервера должна быть проверка всех интегрированных частей и снятие этого бремени с членов команды. Таким образом, вы должны сделать так, чтобы каждый делал коммиты рано (и как можно более аккуратно), а затем следил за состоянием сборок (обычно включаются уведомления). И опять же, если что-то нарушается из-за коммитов какого-либо разработчика, он сразу же становится его обязанностью исправить это и немедленно вернуть эти автоматические сборки в нормальное состояние.
Так что, на мой взгляд, каждый проект выигрывает от непрерывной интеграции. Дело в том, что до сих пор и из-за ошеломляющей сложности каждого отдельного CI-сервера люди действительно отбивались от практики CI в небольших и более простых проектах. Потому что, давай, у людей есть дела поважнее, чем проводить дни, настраивая уродливое, слишком сложное, недоставляющее, раздутое программное обеспечение.
У меня была точно такая же проблема, и именно это заставило меня развивать Cintient в свободное время примерно год назад. Моя предпосылка состояла в том, чтобы сделать его простым в установке, настройке и использовании, а также обеспечить его на основе тех показателей качества, которые все остальные в значительной степени терпят неудачу или недопоставки. Итак, после этого длинного ответа приходит мой бесстыдный плагин, указывающий на ссылку GitHub для проекта (которая является бесплатной и с открытым исходным кодом, естественно). У этого также есть некоторые хорошие скриншоты, очевидно. :-) https://github.com/matamouros/cintient
Надеюсь, я тебе помог.
(ПРИМЕЧАНИЕ: отредактировано после комментария Брайана Окли о том, что мне нужно было больше времени, чтобы найти лучший ответ. Я также думаю, что он был прав.)