Что общего у технологии разработки и эксплуатации приложений DevOps с открытым программным обеспечением? Может показаться, что не так уж много. Компании, использующие DevOps, часто работают с закрытым кодом, а методология DevOps разрабатывалась независимо от движения открытого кода. Строго говоря, между DevOps и открытым исходным кодом нет никакой прямой связи. Однако на концептуальном уровне у них много общего. В самом деле, методологии DevOps не существовало бы без культурных инноваций, внедрению которых способствовало движение открытого программного обеспечения.
Чем же методология DevOps обязана открытому исходному коду?
Прежде всего, хочу подчеркнуть очевидное: DevOps ни полностью, ни частично не дублирует экосистему программного обеспечения с открытым исходным кодом. Без сомнения, некоторые открытые технологии необходимы для многих современных групп, использующих DevOps. Мир DevOps был бы совсем другим без открытых инструментов, таких как Jenkins, Kubernetes, Chef, и контейнеров DOCKER.
В то же время, однако, существует ряд важных технологий DevOps, которые не относятся к числу открытых. Например, бессерверные вычислительные службы от основных «облачных» поставщиков являются закрытыми, как и почти все в общедоступном «облаке». Различные платформы автоматизации DevOps и средства обеспечения безопасности микрослужб тоже не являются открытыми, как и многое другое. Чтобы не выглядеть беспристрастным, я не буду называть имена, но поставщиков закрытого программного обеспечения, ориентированных на рынок DevOps, определить несложно. Вывод: открытый исходный код не является необходимым атрибутом DevOps. Вполне возможно построить успешную платформу или службу DevOps без использования открытого программного обеспечения.
DevOps и открытый исходный код: концептуальная связь
Однако на более глубоком уровне каждый, кто успешно работает с DevOps, во многом обязан тем принципам, подходам и процессам, начало которым было положено благодаря разработке программ с открытым исходным кодом. Все организации, использующие DevOps, следуют перечисленным ниже принципам, сформировавшимся в значительной мере в рамках движения открытого исходного кода.
Быстрый выпуск программного обеспечения
Маловероятно, чтобы непрерывное развертывание программного обеспечения изобрели программисты открытого кода. Но именно они внедрили идею, согласно которой программное обеспечение должно выпускаться своевременно и часто.
Чтобы оценить новаторскую роль сообщества разработчиков программного обеспечения с открытым исходным кодом, вернемся мысленно в начало 1990-х, когда понятия открытого программного обеспечения еще не существовало, а бытовал термин «бесплатное программное обеспечение». В то время пользователи привыкли годами ждать появления новых версий операционных систем и приложений. Когда же эти версии наконец появлялись, обычно приходилось ждать присылки диска по почте, потому что лишь малое число пакетов программного обеспечения предоставлялось через общедоступную сеть.
Результатом такого медленного темпа разработки и распространения программного обеспечения стало то, что программисты в то время действовали в соответствии с известным принципом, предложенным Фредом Бруксом в книге «Мифический человеко-месяц». По словам Брукса, хорошее программное обеспечение — это как изысканное блюдо. Его создание требует времени. Лучше потратить много времени на работу над проектом и попытаться разобраться во всех ошибках до очередного релиза, чем снабжать пользователей быстрыми обновлениями.
Затем, в 1991 году, на сцену вышел проект ядра Linux. Линус Торвальдс, тогдашний 20-летний разработчик Linux, мыслил совершенно иначе, чем большинство программистов того времени. Он выпустил в свободное плавание свой исходный код, прошедший лишь минимальную проверку, рассчитывая на помощь пользователей в исправлении многочисленных ошибок, с которыми они неизбежно должны были столкнуться. Сегодня об этом забыли, но в свое время это стало важнейшим событием. Редакторы Linux Journal тогда писали, что количество и частота выпуска новых версий Linux, драйверов и утилит «поражает всех, кто знаком с традиционными циклами разработки UNIX».
Концепция выпуска программного обеспечения часто и небольшими фрагментами в противоположность долгому ожиданию выхода основных версий платформ дали Linux необходимый импульс к опережению других Unix-подобных операционных систем, а также Microsoft. Кроме того, это послужило прецедентом для того, что мы сегодня называем непрерывным развертыванием.
Оперативность и гибкость
Способность создавать гибкие наборы инструментов и при необходимости переключаться с одного инструмента на другой — важное свойство DevOps, обеспечивающее динамичную разработку ПО. Развертывание программного обеспечения гораздо менее эффективно, если вы жестко привязаны к конкретным средствам разработки и платформам.
Сегодня инженеры, использующие DevOps, как должное принимают то, что большинство инструментов взаимозаменяемы, стандарты и протоколы открыты, а привязка к поставщикам ограничена. Если бы не движение открытого кода, этого могло и не быть. Одним из великих достижений сообщества разработчиков программного обеспечения с открытым исходным кодом стало продвижение идеи о том, что жесткая привязка к платформе подавляет творчество и что на основе принципа открытости можно построить лучший мир.
Желание уйти от жесткой привязки было одной из причин завоевания открытыми платформами, такими как Linux и веб-сервер Apache, столь высокой популярности в 1990-х, когда поставщики закрытого программного обеспечения строили свои бизнес-стратегии на основе привязки клиентов. Оно также стимулировало обратную разработку платформ, таких как протокол Microsoft SMB, с помощью открытых проектов вроде Samba.
Еще большим благом, чем собственно открытый исходный код, является то, что движение открытого кода способствовало широкому внедрению открытых стандартов. Сегодня даже компании — разработчики программного обеспечения, чей бизнес строго закрыт, вынуждены уважать открытые стандарты и протоколы, потому что в противном случае рынок не примет их всерьез. С точки зрения DevOps это хорошо.
«Чем больше людей изучают код, тем проще найти ошибки»
Одним из девизов сообщества разработчиков программного обеспечения с открытым исходным кодом в 90-х годах стало то, что Эрик Рэймонд назвал законом Линуса, согласно которому (в формулировке Рэймонда), «чем больше глаз, тем быстрее ошибки всплывут на поверхность». Рэймонд имел в виду, что чем больше людей изучают код, тем проще выявить все его уязвимые места.
Такое видение предполагает постоянное и непрерывное сотрудничество, которое сегодня является центральным принципом DevOps. Концепция DevOps относит к числу приоритетных задач удаление «барьеров», ограничивающих прозрачность процесса развертывания программного обеспечения и препятствующих свободному взаимодействию инженеров разных специальностей. В основе этого лежит идея о том, что максимальная прозрачность максимально увеличивает шансы найти и исправить ошибки на начальном этапе развертывания, когда это сделать легче всего.
Речь не идет о предоставлении открытого доступа к исходному коду всем желающим, а не только программистам. Но идея, согласно которой специалист по информационно-техническому обслуживанию (IT Ops), которому предоставлена возможность тесно сотрудничать с разработчиками, способен выявить проблему кода, неочевидную для разработчика, имеет много общего с законом Линуса.
Работа над ошибками
Если, подобно большинству групп, использующих DevOps, вы отдаете предпочтение частым выпускам программного обеспечения в противовес затяжному кропотливому анализу кода, предшествующего его выпуску, то вы должны принять тот факт, что будете периодически выпускать код, содержащий ошибки. Этот риск является неотъемлемой частью непрерывного развертывания.
Вместо того чтобы жить с этим риском, инженеры DevOps реагируют на неудачи, следуя концепции работы над ошибками. Иными словами, когда в коде возникает проблема, они стремятся извлечь урок и быстро ее устранить, чтобы создать лучший продукт. В определенном смысле, в рамках концепции DevOps и непрерывного развертывания, всякая неудача — благо, так как она помогает организациям быстрее внедрять инновации.
Работа над ошибками — концепция, популяризации которой способствовали разработчики открытого программного обеспечения. Быстрые циклы выпуска версий платформ, таких как Linux, несли в себе риск возникновения ошибок выше среднего, но это был негативный побочный эффект быстрого внедрения инноваций, заключенных в подобных проектах. В первое время в некоторых открытых проектах выявлялись серьезные проблемы, которые в конечном итоге были решены благодаря готовности программистов принять их и извлечь из них уроки.
Именно из-за принятия неудач, в частности, Mozilla Firefox смог превратиться в один из наиболее широко используемых веб-браузеров, несмотря на то что в 1999 году, вскоре после рождения открытого проекта Mozilla, его ведущий разработчик заявил, что это «полный провал».
Таким образом, DevOps и открытое программное обеспечение — разные идеологии и движения в сфере ИТ. Однако у них есть общие ключевые концептуальные особенности. Если бы разработчики программного обеспечения с открытым исходным кодом не продвигали новаторские идеи, такие как быстрые выпуски версий программного обеспечения, противостояние жесткой привязке к поставщикам и принятие неудач как блага на пути внедрения инноваций, методологии DevOps могло бы и не существовать.
Шаги влево и вправо
Как группы DevOps могут применять «сдвиг влево» и «сдвиг вправо» на пути реализации непрерывного развития. В статье объясняется значение терминов «сдвиг влево» и «сдвиг вправо» и даются рекомендации по применен?ию этих концепций группами, использующими методологию разработки и обслуживания приложений DevOps, для достижения высокого уровня инновационной активности
Сегодня доставка программного обеспечения напоминает контрданс. Группам DevOps говорят о необходимости «шага влево» или «шага вправо» и при этом им даются указания придерживаться «непрерывного цикла обратной связи» или других циклических процессов. Каково значение понятий сдвига влево и вправо в данном случае? Может, это просто расхожие слова, не несущие реального смысла?
Если отвечать коротко, то нет, это не просто слова. Тем не менее, бывает сложно разобраться в том, как продуктивно применять сдвиг влево и сдвиг вправо. На фоне разговоров об этом легко увязнуть в ненужных деталях.
В этой статье я поясню значение понятий сдвига влево и вправо и дам рекомендации по применению соответствующих концепций группами DevOps для достижения высокого уровня активности кодирования и развертывания программного обеспечения в режиме непрерывной разработки.
Что такое сдвиг влево
Говоря простыми словами, под сдвигом влево понимается выполнение конкретного процесса в более ранний момент времени в цепочке развертывания программного обеспечения. Если рассматривать цепочку развертывания как конвейер, у которого в крайней левой позиции находится разработка, а в крайней правой — запуск в производство, то смещение процесса влево означает более раннюю его реализацию.
Основная идея сдвига влево состоит в том, что более раннее выполнение процесса в цепочке развертывания упрощает обнаружение и устранение проблем. Чем дольше вы ждете, тем выше риск, что устранение одной проблемы в приложении потребует изменения других его частей, поскольку они зависят от того, что явилось причиной исходной проблемы.
Что можно сдвигать влево? Тестирование, безопасность и многое другое. Сегодня сдвиг влево обычно обсуждается применительно к тестированию программного обеспечения или информационной безопасности. Эти процессы — очевидные кандидаты на такой сдвиг. Ошибки программного обеспечения и уязвимости систем безопасности, как правило, устраняются тем легче, чем раньше они выявляются в группах DevOps.
Однако сдвиг влево применим к любому типу процесса в цепочке развертывания. Управление данными, мониторинг программного обеспечения и даже маркетинг программного обеспечения также могут быть сдвинуты влево.
Что такое сдвиг вправо
При сдвиге влево процессов анализа информационной безопасности, тестирования программного обеспечения и т. д. возникает риск оставить без внимания части конвейера развертывания, относящиеся к более поздним моментам.
Например если в вашем конвейере разработки приоритет отдан выполнению модульного и комплексного тестирования на раннем этапе цепочки, то у вас может возникнуть недостаток ресурсов для проведения приемочного тестирования пользователями (UAT) или других форм тестирования, обычно относящихся к более поздним моментам. Это проблема, поскольку экономия на UAT может привести к тому, что ошибки программного обеспечения, не выявленные в ходе тестов, проведенных на более ранних этапах, останутся незамеченными после запуска программного обеспечения в производство.
Именно в свете решения этой проблемы возникла концепция сдвига вправо. Нетрудно догадаться, что такой сдвиг означает выполнение процесса на более позднем этапе в цепочке конвейера. В частности, во многих случаях это означает перенос процессов, обычно предшествующих выпуску приложений, на этап запуска в производство, что позволит диагностировать проблемы, выявляемые после выпуска продукта, до того, как они будут обнаружены конечными пользователями.
Термин «сдвиг вправо» звучит не так часто, как «сдвиг влево», однако такой сдвиг все чаще становится темой для дискуссий о доставке программного обеспечения.
Сдвиг влево и сдвиг вправо означают непрерывность
Легко предположить, что участники разговоров о сдвиге влево и вправо просто используют расхожие термины, не вкладывая в них реальный смысл. Когда вам говорят о значении сдвига влево и вправо, о чем на самом деле идет речь? Нельзя ведь двигаться в одно и то же время в противоположных направлениях.
Легко признать ценность выполнения процесса на этапе более раннем или более позднем, чем обычно, но проблема в том, что такие термины, как «сдвиг влево» и «сдвиг вправо», заставляют предположить, что речь идет исключительно о переносе процесса целиком влево или вправо по цепочке развертывания.
На самом деле в большинстве случаев группы DevOps должны стремиться сделать процессы тестирования и анализа информационной безопасности непрерывными. Процессы, сегодня выполняемые в середине цепочки развертывания, следует расширить таким образом, чтобы они начинались раньше и заканчивались позже. Именно такая идея стоит за разговорами о сдвиге влево и вправо. Однако этот смысл легко упустить, поскольку термины «сдвиг влево» и «сдвиг вправо» можно истолковать неверно.
Ни один процесс не является монолитным
Стоит отметить, что процессы, которые следует делать непрерывными, по своей природе не являются монолитными. Имейте это в виду, растягивая их по цепочке развертывания.
Например, тестирование программного обеспечения — неоднородный процесс. Существуют разные типы тестирования, и одни лучше подходят для сдвига влево или вправо, чем другие. Как уже говорилось выше, базовые тесты, например комплексные и модульные, целесообразно перемещать в левую часть конвейера разработки. При этом нет смысла проводить комплексное тестирование на этапе запуска в производство. Напротив, к более сложным случаям, таким как приемочное тестирование, применим сдвиг вправо.
То же относится и к информационной безопасности. Если требуется применить сдвиг влево к этой сфере, то можно начать с того, чтобы сделать сотрудничество специалистов по безопасности с разработчиками более тесным, чтобы уже на начальном этапе конвейера обеспечить написание безопасного кода. Между тем другие аспекты безопасности, такие как усиление защиты среды выполнения, можно перенести вправо. При этом, безусловно, следует оставить на прежнем месте моменты выполнения проверок безопасности, предшествующих выпуску, которые обычно приходятся на середину конвейера.
«Сдвиг влево» и «сдвиг вправо» — важные концепции, но группы DevOps не должны применять их изолированно. Сдвиг влево и вправо следует рассматривать как шаги, направленные на обеспечение непрерывности основных процессов развертывания программного обеспечения, таких как тестирование и анализ информационной безопасности, по всему конвейеру.