Чистый Agile. Основы гибкости

3. Положить главную ленту на место, чтобы другие могли получить доступ к прочим модулям.

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

5. Редактировать, компилировать и тестировать на ленте с рабочей копией.

6. Снова достать главную ленту.

7. Скопировать измененные модули с ленты с рабочей копией на главную ленту.

8. Положить обновленную главную ленту в стойку.

9. Вынуть кнопку из доски.

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

Разумеется, эти модули были и на главной ленте, и в крайнем случае кто-нибудь мог в обход правил отредактировать модули непосредственно на ней. Кнопки были условным соглашением, но никак не физической преградой.

Диски и системы управления исходным кодом

В 1980-х годах исходные коды переместились на диски. Поначалу еще использовалась доска выдачи и кнопки, но потом начали появляться настоящие средства управления исходным кодом. Первое из того, что я помню, — это Система управления исходным кодом (SCCS). Она работала по тому же принципу, что и доска выдачи. Происходила блокировка модуля на диске, из-за чего никто не мог получить доступ к его редактированию. Такое блокирование называется пессимистическим. И снова то же самое. Длительность цикла зависела от длительности блокирования. Блокировка могла длиться часами, днями, а то и месяцами.

На смену Системе управления исходным кодом пришла Система управления редакциями (RCS), которая, в свою очередь, уступила место Системе одновременных версий (CVS). Во всех так или иначе применялась пессимистическая блокировка. Поэтому цикл по-прежнему длился долго. Тем не менее хранение данных на диске было куда удобнее, чем на магнитной ленте. При копировании модулей с оригинала на ленту с рабочей копией очень соблазнительно было сделать модули крупными сами по себе.

С другой стороны, диски позволяли нам стремительно уменьшать размер модулей. Множество маленьких модулей просто-напросто не вело к таким издержкам, как несколько крупных. За счет уменьшения модулей продолжительность цикла стала короче, поскольку количество времени, затрачиваемое на проверку модуля, также относительно уменьшилось.

Проблема состояла в том, что изменения в программе влекли за собой изменения во многих модулях. В случаях, когда модули были тесно связаны, на их проверку все еще уходило много полезного времени. Некоторые из нас научились отделять связанные модули, чтобы уменьшить эти сроки. А кто-то так и не научился.

Subversion

Потом пришло время системы Subversion (SVN). В ней появилось оптимистическое блокирование. Оптимистическое блокирование по сути никакое и не блокирование. Разработчик мог проверять модуль одновременно с другим разработчиком. Система позволяла отслеживать действия разработчиков и автоматически объединять изменения в модулях. Если система обнаруживала конфликт, когда два разработчика работали над одними и теми же строками кода, то вынуждала программиста сперва разрешить этот конфликт, прежде чем подтвердить принятые изменения.

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

Git и тесты

В наши дни мы используем Git. Сроки проверки при использовании Git сошли на нет. Это понятие больше не существует. Напротив, любое изменение в модуль можно внести когда угодно. Программисты разрешают конфликты между этими изменениями, как и когда этого пожелают. Маленькие несвязанные модули позволяют молниеносно и часто вносить изменения. Поэтому циклы составляют считаные минуты. Добавьте к этому возможность создавать всеобъемлющие и быстрые тестовые наборы, которыми можно протестировать практически все. Вот вам и все нужное для непрерывной доставки.

Историческая инерция

К сожалению, организации с трудом отказываются от унаследованных подходов. Циклы продолжительностью в дни, недели и месяцы глубоко укоренились в культуре многих команд, откуда затем перешли к QA-специалистам, менеджерам и даже заинтересованным сторонам. С колокольни такой «культуры» мысль о непрерывной доставке может показаться бредом сумасшедшего.

Небольшие и частые релизы