Как обеспечить качественную проверку с помощью систем непрерывной сборки?

Question

Я тщательно проверяю весь свой код, прежде чем регистрировать его, выполняю разбор кода «до» и «после», читаю его и проверяю, насколько я недооцениваю изменения. Обычно я заканчиваю тем, что добавляю комментарии, изменяю имена переменных, изменяю алгоритмы, исправляю код, повторно тестирую вещи, обсуждаю с другими разработчиками их код, добавляю новые ошибки / проблемы, но я очень редко заканчиваю проверку немедленно.

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

Какие существуют лучшие практики для обеспечения того, чтобы в системы непрерывной сборки входил только качественный код?

Answer 1

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

По моему мнению, использование непрерывной сборки для "проверки" - это действительно плохая практика, разработчики должны всегда стараться не фиксировать плохой код, который может повлиять на команду и прервать работу (почему настолько очевидно, что если вы этого не получите, просто ищите другую работу). Итак, если ваш движок CI не предлагает предварительно протестированный коммит (например, TeamCity , Team Foundation Server , как я только что видел, возможно, Hudson один день и т. Д.), Прежде чем совершать коммит, вы всегда должны синхронизировать / строить / синхронизировать (и перестраивать при необходимости) локально. Не делать это лень и не уважать команду.

Какие существуют лучшие практики для обеспечения того, чтобы в системы непрерывной сборки входил только качественный код?

• На всякий случай напомните, почему нарушение сборки является плохим: плохой код потенциально влияет на команду целом и прерывает работу (вздох).
• Если вы можете получить поддержку инструмента (см. Вышеупомянутые решения), получите ее.
• Если нет, документируйте правильный рабочий процесс: 1. синхронизация 2. сборка локально 3. синхронизация 4. возврат к 2 при необходимости 5. фиксация. Сделайте это видимым, чтобы не было оправданий.
• Если это вариант, используйте что-то вроде (или похожее) на плагин Hudson's Continuous Integration Game . Это может сделать вещи веселее.

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

Answer 2

В Team Foundation Server есть то, что называется проверка перед проверкой .