Джин Ким - Руководство по DevOps

Здесь есть возможность читать онлайн «Джин Ким - Руководство по DevOps» весь текст электронной книги совершенно бесплатно (целиком полную версию без сокращений). В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. Город: Москва, Год выпуска: 2018, ISBN: 2018, Издательство: Манн, Иванов и Фербер, Жанр: Интернет, Базы данных, Прочая околокомпьтерная литература, на русском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

Руководство по DevOps: краткое содержание, описание и аннотация

Предлагаем к чтению аннотацию, описание, краткое содержание или предисловие (зависит от того, что написал сам автор книги «Руководство по DevOps»). Если вы не нашли необходимую информацию о книге — напишите в комментариях, мы постараемся отыскать её.

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

Руководство по DevOps — читать онлайн бесплатно полную книгу (весь текст) целиком

Ниже представлен текст книги, разбитый по страницам. Система сохранения места последней прочитанной страницы, позволяет с удобством читать онлайн бесплатно книгу «Руководство по DevOps», без необходимости каждый раз заново искать на чём Вы остановились. Поставьте закладку, и сможете в любой момент перейти на страницу, на которой закончили чтение.

Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

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

Вместо входа на серверы вручную и внесения изменений в конфигурацию мы должны внести изменения таким образом, чтобы все они автоматически реплицировались всюду и автоматически же фиксировались в системе контроля версий. Мы можем полагаться на нашу систему управления конфигурацией для обеспечения согласованности сред (например, Puppet, Chef, Ansible, Salt, Bosh и др.). Можно создавать новые виртуальные машины или контейнеры с помощью механизма автоматизированной сборки и развертывать их в производство, уничтожая старые машины или выводя их из ротации [69].

Последняя модель — так называемая постоянная инфраструктура: в ней внести изменения в производственную среду вручную невозможно, единственный способ — внести изменения в систему контроля версий и создать код и среду «с нуля». При таком подходе вариабельность никак не сможет «вползти» в производственную среду.

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

Также мы должны поддерживать в актуальном состоянии предпроизводственные среды — в частности, необходимо сделать так, чтобы разработчики максимально обновленный вариант среды. Разработчики часто стремятся работать в старых средах, поскольку не любят изменений: так можно нарушить работу имеющихся функций. Однако мы хотим обновлять среды часто, чтобы можно было обнаруживать проблемы на как можно более ранней стадии жизненного цикла проекта [71].

Измените для разработчиков определение состояния «выполнено», чтобы оно включало выполнение в среде, приближенной к производственной

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

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

Наша цель — обеспечить, чтобы разработчики и тестировщики регулярно интегрировали код в среду, близкой к производственной, с интервалами, постепенно сокращающимися по мере выполнения проекта [72]. Мы делаем это путем расширения определения «выполнено» за границы правильного функционирования кода: в конце каждого интервала разработки мы должны иметь интегрированный, протестированный, работающий и потенциально готовый к поставке код, указанные характеристики которого продемонстрированы в среде, близкой к производственной.

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

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Похожие книги на «Руководство по DevOps»

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


Николь Форсгрен - Ускоряйся! Наука DevOps
Николь Форсгрен
Отзывы о книге «Руководство по DevOps»

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

x