Обсуждение:Непрерывная интеграция

Сомнительные минусы

Перенесено со страницы Обсуждение Википедии:Подписывайтесь.

"потенциальная необходимость в выделенном сервере под нужды непрерывной интеграции" - сомнительный минус. Если проболжить - то в минусы можно записать необходимость писать код на ПК, а не на бумаге.

"затраты на поддержку работы непрерывной интеграции;" - затраты такие: ночью запускаете сборку ,а днем комунибуть нужно будет уже довершить сборку(около ролу часа, как правила). Возможен случай, когда вся зборка автоматизирована.

89.178.254.205 15:51, 16 декабря 2007 (UTC) QC

• Минусы объективны. Я в компании назначен "админом" сборочного сервера. И это постоянная головная боль несмотря на то, что сборка полностью автоматизирована. Регулярно что-то перестаёт собираться, и я должен определить, что именно и как исправлять. Необходимость в сервере тоже объективный минус, поскольку это издержки. И не нужно перегибов про необходимость писать код на бумаге. Если серьёзно, то при возникновении проблем с электроэнергией ничего Вы не напишете, а на бумаге ещё во времена Пушкина можно было писать. Дмитрий Мещеряков 05:25, 17 декабря 2007 (UTC)
• Поддерживаю Дмитрия — минусы объективны. Выделенный сервер нужен и стоит денег, поддержка отнимает время. -- NZeemin 06:21, 17 декабря 2007 (UTC)
• Не согласен. Под сборочный сервер можно поначалу взять любой старый компьютер. Что касается сломанных сборок — чинить должен строго тот, кто сломал. В его интересах сделать это не особенно позже своего коммита, иначе его достаёт админ. В интересах админа дать ему возможность сделать это самостоятельно без отталкивающих проблем, например — настроить удаленный доступ на рабочий стол сервера, где лежит свежесломанная сборка и есть все инструменты для работы. —Pavel 20:57, 23 февраля 2008 (UTC)
• Это модельный случай. В жизни сборка может сломаться, например, из-за того, что не было доступа к базе, в которой хранится часть необходимых данных. Ответственный за эту базу часто меняется. В результате, когда из-за этого сборка ломается раз в полгода, «админу» (а это я) нужно прочитать два километра логов, понять, в чем именно дело, потом достучаться до того, до кого нужно. Это время. И кстати, зачем вы удалили абзац про суточную сборку? Дмитрий Мещеряков 05:53, 24 февраля 2008 (UTC)
  • Этот абзац вообще не про суточную сборку. Его можно свести к «См. также: Версионинг». -- NZeemin 17:56, 24 февраля 2008 (UTC)
  • Не могу согласиться. Обычно механизм меток рекомендуется для установки «контрольных точек», к которым можно вернуться, если понадобится стабильная версия исходников. Использование сборки по расписанию одновременно с установкой меток вовсе не очевидно. В любом случае этот текст должен где-то быть, я решил, что здесь он более к месту. Дмитрий Мещеряков 05:19, 26 февраля 2008 (UTC)

Отсталость

Что-то тут всё так и осталось в прошлом. Надо бы обновить сведениями (ссылками на статьи, которые тоже нужно создать) о en:Continuous Delivery, Continuous Deployment, ... РоманСузи (обс.) 13:18, 6 декабря 2016 (UTC)