Главная - Литература

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 [227] 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294

Краткий ИТОГ методик интеграции

Восходящая, нисходящая, сэндвич, риск-ориентированная, функционально-ориентированная, Т-образная - не кажется ли вам, что эти названия придумываются на ходу? Так и есть. Ни один из этих подходов не является жесткой процедурой, которой вы должны методично следовать, начиная с шага 1 и заканчивая шагом 47, а затем объявить задание выполненным. Как и другие подходы к проектированию ПО, они скорее эвристические, чем алгоритмические. Поэтому вместо того, чтобы безусловно следовать какой-то процедуре, вам придется разработать свою уникальную стратегию, подходящую именно вашему проекту.

29.4. Ежедневная сборка и дымовые тесты

Дояо/шиттнь» (шешя Боль- i стратегию интеграции вы и выбрали, хорошим

шая часть этого материала по- подходом к разработке ПО является «ежедневная сборка и

заимствована иа главы 18 кни- дымовые тесты» (daily build and smoke test). Ежедневно каж-

ги «Rapid Oevetopment» (McCon* дый файл компилируется, компонуется и собирается в вы-

neU. 1996). Если вы ее читали, полняемую программу. После чего прогоняется «дымовой

**uf«tll.!!!!!f тест» - относительно простая проверка, определяющая,

<*г1епрерывная интвграчия>».

«дымится» ли продукт во время выполнения

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

Этот процесс также поддерживает упрощенную диагностику ошибок. Когда продукт собирается и тестируется каждый день, легко засечь, почему его работа в определенный день была нарушена. Если проект работал на 17-й день, а на 18-й перестал, то нечто, происшедшее между этими двумя сборками, и нарушило работу продукта.

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

У частой интеграции есть побочный эффект: она выявляет такие проблемы, какие в противном случае могли бы незаметно накапливаться и неожиданно проявиться в конце проекта. Такое накопление скрытых результатов может стать занозой в конце проекта и потребовать для устранения недели или месяцы. Команды, не применяющие ежедневных сборок, иногда считают, что они могут снизить эффективность их работы до скорости улитки. На самом же деле ежедневные

Термин «дымовой тест» появился в электронике. Разработчики на определенном этапе включают испытываемое устройство в сеть и смотрят, не задымится ли оно. - Пргш. перев.



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

Создавайте сборку ежедневно Основной смысл ежедневной сборки заключен в слове «ежедневная». Как говорит Джим Маккарти, рассматривайте ежедневную сборку как пульс проекта (McCarthy, 1995). Пульса нет - проект мертв. Менее метафорично Майкл Кьюсумано и Ричард Селби определяют ежедневную сборку как синхроимпульс проекта (Cusumano and Selby, 1995). Части кода могут немного рассинхронизироваться между этими импульсами, но каждый раз во время импульса код должен приводиться в соответствие. Когда вы настаиваете на достаточно частых импульсах, вы предотвращаете полное рассогласование частей проекта.

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

Проверяйте правильность сборок Чтобы процесс ежедневных сборок действовал, собираемое ПО должно быть работоспособным. В противном случае сборка считается испорченной, и ее исправление становится приоритетной задачей.

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

«Хорошая» сборка должна как минимум:

успешно компилировать все файлы, библиотеки и другие компоненты;

успешно компоновать все файлы, библиотеки и другие компоненты;

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

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

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

Поддерживайте актуальность дымового теста Дымовой тест должен развиваться по мере развития системы. Поначалу он может проверять что-то простое, скажем, может ли система говорить «Hello, World». По мере разработки системы дымовой тест становится более изощренным. Если выполнение первой про-



верки может быть делом нескольких секунд, то с ростом системы дымовой тест может удлиниться до 10 минут, часа или больше. Если дымовой тест не поддерживается в актуальном состоянии, то ежедневная сборка может стать самообманом: разрозненный набор тестовых данных создает ложную уверенность в качестве продукта.

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

Организуйте группу, отвечающую за сборки В большинстве проектов надзор за ежедневными сборками и поддержание актуальности дымовых тестов становится достаточно большой задачей, чтобы стать заметной частью чьей-то работы. В больших проектах эти задачи могут обеспечить полную занятость для нескольких человек. Например, при выпуске первой версии Microsoft Windows NT группа, ответственная за сборки, состояла из четырех человек, работающих полный рабочий день (Zachary, 1994).

Вносите исправления в сборку, только когда имеет смысл это делать,..

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

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

Требуйте, чтобы разработчики проводили дымовое тестирование своего кода перед его добавлением в систему Программисты должны тестировать собственный код, прежде чем добавить его к сборке. Разработчик может это сделать, создав частную сборку системы на собственной машине и протестировав ее самостоятельно. Или он может передать частную сборку «партнеру по тестированию» - тестировщику который сосредоточится на коде этого разработчика. В обоих случаях цель в том, чтобы убедиться, что новый код пройдет «проверку на дым», прежде чем ему будет позволено влиять на остальные части системы.

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



0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 [227] 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294



0.0119