Вы не можете знать, что такое КИ, если не знаете, что мы делали раньше. Представьте себе систему из 3 частей. Есть пользовательский интерфейс, который собирает данные и помещает их в базу данных. Есть система отчетности, которая делает отчеты из базы данных. И есть какой-то сервер, который контролирует базу данных и отправляет оповещения по электронной почте, если соблюдены определенные критерии.
Давно это было бы написано следующим образом:
- Согласуйте схему базы данных и требования - это займет недели, потому что она должна быть идеальной, поскольку вы скоро поймете, почему
- Назначьте 3 части или 3 независимых команды разработчиков на 3 части
- Каждый разработчик работал бы над своей частью и проверял ее, используя свою собственную копию базы данных, в течение нескольких недель или месяцев.
В течение этого времени разработчики не запускали код друг друга и не пытались использовать версию базы данных, созданную чужим кодом. Автор отчетов просто добавит несколько примеров данных. Автор оповещения вручную добавит записи, имитирующие события отчета. И писатель GUI будет смотреть на базу данных, чтобы увидеть, что GUI добавил. Со временем разработчики поймут, что спецификация в некотором роде неверна, например, не указание индекса или слишком короткая длина поля, и «исправление» в своей версии. Они могут рассказать остальным, кто может действовать, но обычно эти вещи попадают в список на потом.
Когда все три части были полностью закодированы и протестированы их разработчиками, а иногда даже протестированы пользователями (показывая им отчет, экран или оповещение по электронной почте), наступает фаза «интеграции». Это часто планировалось на несколько месяцев, но все равно продолжалось. Это изменение длины поля на dev 1 будет обнаружено здесь, и потребуются dev 2 и 3, чтобы сделать огромные изменения кода и, возможно, изменения пользовательского интерфейса. Этот дополнительный индекс нанесет свой собственный ущерб. И так далее. Если бы один из разработчиков сказал пользователю добавить поле, и он сделал это, сейчас настало время, когда два других должны были добавить его также.
Этот этап был чрезвычайно болезненным и почти невозможно предсказать. Люди стали говорить: «Мы должны чаще интегрироваться». «Мы должны работать вместе с самого начала». «Когда один из нас поднимает запрос на изменение [так мы тогда говорили], другие должны знать об этом». Некоторые команды начали проводить интеграционные тесты ранее, продолжая работать отдельно. И некоторые команды начали использовать код друг друга и выводить все время, с самого начала. И это стало непрерывной интеграцией.
Вы можете подумать, что я преувеличиваю эту первую историю. Однажды я выполнил какую-то работу для компании, где мой собеседник разжевал меня за проверку некоторого кода, который страдает от следующих недостатков:
- экран, над которым он не работал, имел кнопку, которая еще ничего не делала
- никто не подписывался на дизайн экрана (точные цвета и шрифты; наличие экрана, его возможности и какие кнопки были в спецификации на 300 страниц).
Это было его мнение, что вы не помещаете вещи в систему контроля версий, пока они не СДЕЛАНЫ. Обычно он делал один или два чеканы в ГОД. У нас была небольшая разница в философии :-)
Кроме того, если вам трудно поверить, что команды будут разъединены вокруг общего ресурса, такого как база данных, вы действительно не поверите (но это правда), что тот же подход был применен к коду. Вы собираетесь написать функцию, которую я могу вызвать? Это здорово, продолжайте и сделайте это, я просто напишу то, что мне нужно в это время. Месяцы спустя я «интегрирую» свой код, чтобы он вызывал ваш API, и мы обнаружим, что он взрывается, если я передаю ноль, я взрываюсь, если он возвращает ноль (и это часто), он возвращает слишком большие объекты для меня это не может справиться с високосными годами и тысячами других вещей. Работать независимо, а затем иметь фазу интеграции было нормально. Теперь это звучит как безумие.
