DevOps
Основные концепции DevOps Core и Pipeline Building
Задачи разработки и эксплуатации для лучшего управления SDLC
DevOps - это практика разработки приложений, которая объединяет задачи разработки и операционные задачи для лучшего управления жизненным циклом разработки программного обеспечения, одновременно обрабатывая частые обновления, ошибки и функции приложения.
DevOps включает в себя задачи непрерывной разработки, такие как планирование кода, кодирование, построение кода и его тестирование, наряду с непрерывными операционными задачами, такими как выпуск кода, его развертывание, эксплуатация и мониторинг, с последующей непрерывной интеграцией обоих наборов задач.
Основные концепции DevOps:
- Непрерывная сборка - это непрерывный и автоматизированный процесс сборки. Он запускает добавленные или измененные коды.
- Непрерывная интеграция - это автоматическая сборка и выполнение как минимум модульных тестов для подтверждения интеграции нового кода с существующим кодом, но предпочтительно интеграционные тесты (сквозные). Это практика автоматического создания и модульного тестирования всего приложения часто, в идеале, при каждой проверке исходного кода, десятки раз в день, если это необходимо.
- Непрерывная доставка - это дополнительная практика развертывания каждого изменения в производственной среде и выполнения автоматической интеграции и приемочного тестирования после прохождения сборки и модульных тестов. CD может включать развертывание на локальном сервере, создавая среду с помощью докер-контейнеров или виртуальные машины настраиваются для выполнения производственной среды, аналогичной интеграционным тестам. Тестирование обычно приводит к развертыванию аналогичной производственной среды. Это позволяет нам проверять процесс развертывания, а также проверять и отслеживать функциональность среды в реальном мире.
- Непрерывное развертывание расширяет концепцию непрерывной доставки до уровня, когда любая модификация проходит полное автоматическое тестирование, а затем развертывается в производственной среде.
Создание конвейеров на практике:
Конвейер сборки - это последовательная комбинация инструментов и операций, которая выполняет назначенные задачи, начиная от исходного кода и заканчивая развернутой системой. Общие инструменты, используемые для репозитория исходного кода, включают Git, Perforce или Subversion. Эти инструменты предоставляют услуги по хранению и управлению конфигурацией для всех приложений, использующих hapcode, сценариев развертывания и определений инфраструктуры. Его задача - обрабатывать код, защищать его, управлять версиями и обрабатывать одновременные фиксации кода.
Система сборки
Затем следует система сборки, которая отслеживает репозиторий и запускает сборку кода всякий раз, когда запрашивается изменение. Jenkins, Bamboo и TeamCity - популярные системы сборки. Circle CI и Travis CI - некоторые из доступных онлайн-сервисов. Любые сценарии сборки, которые вы соберете и можете запустить make, также подойдут. Но некоторые функции, такие как веб-перехватчики, внешние плагины и другие функции, которые помогут вам оптимизировать процесс, будут упущены в этих кодах. Его задача - создавать код и запускать модульные тесты. И, конечно же, чтобы обеспечить обратную связь и наглядность процесса сборки.
В зависимости от того, какой язык вы используете, у вас может быть множество инструментов для компиляции и построения оркестровки. Если это скомпилированный язык, вам может понадобиться компилятор c или go. Интерпретируемые языки могут не иметь этапа компиляции и сразу переходить к упаковке.
У вас может быть файл определения сборки, такой как файл make или файл докера, или, возможно, вы используете что-то вроде Maven, Ant или Gradle в качестве инструмента оркестровки сборки из командной строки. Это позволяет разработчикам создавать на своих локальных машинах и сохранять как можно больше кода в системе управления версиями и вне конфигурации консоли сборки.
У вас, вероятно, есть программа модульного тестирования, которая может быть отдельным инструментом, но вызывается внутри системы сборки. Модульные или базовые тесты, предназначенные для проверки того, что фрагмент кода выполняет работу, для которой он был предназначен. Модульные тесты не зависят от внешних систем. В лучшем случае они издеваются над чем-либо за пределами своей кодовой базы. Они являются вашей первой линией защиты при определении того, будет ли ваша сборка работать должным образом.
Упаковка
Следующий шаг - упаковка того, что вы создали, в артефакт. Частично это обычно зависит от языка. Например, код Java обычно помещается в файлы JAR, а затем они объединяются в файл WAR или EAR. Но у вас может быть структура упаковки более высокого уровня, которую вы предпочитаете, например пакет RPM или образ докера. После того, как вы упаковали код, он попадает в репозиторий артефактов.
Некоторые люди просто используют запоминающее устройство или Amazon S3 для своих артефактов. Другие используют инструменты, созданные для работы, такие как Nexus или Artifactory. Или есть технологические перерывы, такие как реестры докеров или Puppet Forges. Раньше инженер-строитель думал, что здесь все сделано. Но это не так. У вас есть кое-что на диске, а не услуга, приносящая пользу клиентам, поэтому ваша работа не выполнена. Вам нужен инструмент развертывания, чтобы запустить рабочий экземпляр для вашей службы. Вы будете использовать один и тот же инструмент для развертывания как тестовой, так и производственной среды.
Ваш код развертывания - это код, и, как и любой другой код, вы хотите найти проблемы в цикле сборки и тестирования, а не при развертывании в производственной среде. Таким образом, вы запускаете свой инструмент развертывания в тестовой среде, иногда также называемой средой CI, чтобы ваш сервис начал работать.
Затем вы выполняете интеграционное тестирование, которое предназначено для тестирования реальной работающей службы в реальной среде и обеспечения ее правильной работы. Затем у вас есть сквозной этап приемочных испытаний. Это может включать компонент ручного тестирования. От ручных тестов в большинстве случаев можно отказаться, когда вы достигнете зрелости процесса CD, но почти всегда они будут преобладать на начальном этапе.
Затем вы используете тот же артефакт, который прошел тестирование, и тот же инструмент развертывания для его развертывания в производственной среде. В идеале вы должны использовать одни и те же приемочные тесты, чтобы проверить это и там. Есть еще много типов инструментов, которые вы можете наложить на свой конвейер, инструменты измерения тестового покрытия, линтеры, инструменты тестирования безопасности, инструменты тестирования производительности, но это основы. А знание основ - это ключ к непрерывной интеграции, а затем, если вы хотите непрерывное развертывание.
Свяжитесь со мной в моем LinkedIn
