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

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

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

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

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

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

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

Другие проекты устанавливают более существенное наказание. Разработчики наиболее заметных проектов в Microsoft, например, Windows 2000 и Microsoft Office, на последних стадиях проектов должны носить с собой пейджеры. Если они разрушают сборку, их вызывают для ее починки, даже если дефект обнаружен в три часа утра.

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

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



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

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

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

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

На этом фоне ежедневные сборки ужесточают дисциплину и поддерживают на плаву критические проекты.

Для каких проектов применять ежедневную сборку?

Некоторые разработчики считают, что проводить ежедневные сборки непрактично, так как их проекты слишком велики. Но, вероятно, в одном из самых сложных недавних программных проектов успешно использовалась практика ежедневных сборок. К моменту выпуска Microsoft Windows 2000 состояла из примерно 50 миллионов строк кода, распределенных по десяткам тысяч исходных файлов. Полная сборка занимала 19 часов на нескольких машинах, но разработчики Windows 2000 оказались в состоянии проводить сборки каждый день. Они не стали помехой - напротив, команда Windows 2000 видит одну из причин успеха в ежедневных сборках. Чем больше проект, тем большую важность имеет инкрементная интеграция.

При рассмотрении 104 проектов в США, Индии, Японии и Европе выяснилось, что только 20-25% из них используют ежедневные сборки в начале или середине процесса разработки (Cusumano et al., 2003). Таким образом, в них имеются широкие возможности для улучшения.

Непрерывная интеграция

Некоторые авторы расценивают ежедневные сборки как аргумент в пользу выполнения непрерывной интеграции (Веек, 2000). В большинстве публикаций под «непрерывной» понимается «по крайней мере ежедневная» интеграция (Веек, 2000), что мне кажется обоснованным. Но порой я встречаю людей, понимающих слово «непрерывная» буквально: они стремятся выполнять интеграцию каждого изменения с самой последней сборкой каждые пару часов. Думаю, для большинства проектов действительно непрерывная интеграция выходит за рамки разумного.



В свободное время я руковожу работой дискуссионной группы, главных технических менеджеров таких компаний, как Amazon.com, Boeing, Expe-dia, Microsoft, Nordstrom и др. Опрос показал, что никто из руководите-

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

Контрольный список: интеграция

Шр: сс2е.сот/29а2

Стратегия интеграции

□ Определяет ли стратегия оптимальный порядок, в котором должны интегрироваться подсистемы, классы и методы?

□ Скоординирован ли порядок интеграции с порядком конструирования, чтобы классы были подготовлены к интеграции вовремя?

□ Приводит ли стратегия к упрощению диагностики дефектов?

□ Позволяет ли стратегия сократить использование «подпорок» до минимума?

□ Имеет ли выбранная стратегия преимущества перед другими подходами?

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

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

□ Выполняется ли сборка проекта достаточно часто (в идеале каждый день), чтобы поддерживать инкрементную интеграцию?

□ Выполняется ли дымовой тест для каждой сборки так, что вам становится известно, находится ли сборка в рабочем состоянии?

□ Автоматизированы ли сборка и дымовой тест?

□ Часто ли разработчики регистрируют свой код: не превышает ли время между исправлениями день или два?

□ Поддерживается ли дымовой тест в соответствии с кодом, расширяясь при его расширении?

□ Редко ли происходит нарушение работоспособности сборки?

□ Выполняете ли вы сборку и дымовой тест даже в экстремальных обстоятельствах?

Дополнительные ресурсы

Вопросам, обсуждаемым в этой главе, посвящены следующие публикации. mtp: cc2e.com/2999

Интеграция

Lakos, John. Large-Scale С++ Software Design. Boston, MA: Addison-Wesley, 1996. Лей-кос доказывает, что «физическое представление» системы - иерархия файлов, каталогов и библиотек - заметно влияет на способность команды разработчи-



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.0021