Философия DevOps

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

Система выделения ресурсов

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

Система выделения ресурсов (system provisioning) расширяет автоматизацию инфраструктуры, позволяя компаниям определять собственную инфраструктуру. При этом используются не отдельные узлы, а кластеры зависимых систем. Это позволяет сотрудникам задавать отдельную группу серверов, которая будет предоставляться один раз, а затем использовать эту спецификацию автоматически произвольное количество раз.

Автоматизация тестирования и сборки исполняемых файлов

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

Современные инструментальные средства автоматизации обычно специфицируют порядок сборки исполняемых файлов (необходимые шаги и порядок их выполнения). Также определяются требуемые зависимости (другое программное обеспечение, используемое для успешного создания исполняемых файлов). Некоторые инструменты лучше всего подходят для проектов, относящихся к конкретным языкам программирования, таких как Apache Maven и Ant. В то же время эти инструменты могут применяться совместно с другими языками программирования, которые чаще всего используются в проектах Java. Другие же инструменты, такие как Hudson или Jenkins, могут использоваться для большего диапазона проектов.

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

Автоматизация по требованию

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

Запланированная автоматизация

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

Условная автоматизация

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

ТЕСТЫ, МОНИТОРЫ И ДИАГНОСТИКА по Ивонн Лам

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

Во время выступления на конференции Sysadvent 2014 (http://sysadvent.blogspot.com/2014/12/day-5-how-to-talk-about-monitors-tests.html) Ивонн Лам определила ряд вопросов, на которые должна ответить команда, чтобы сформировать общий контекст на основе тестов, мониторов и диагностики.

• Где будут выполняться тесты?

• Когда будут выполняться тесты?

• Как часто они будут проводиться