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

Тут можно читать онлайн Джин Ким - Руководство по DevOps - бесплатно ознакомительный отрывок. Жанр: Интернет, издательство Манн, Иванов и Фербер, год 2018. Здесь Вы можете читать ознакомительный отрывок из книги онлайн без регистрации и SMS на сайте лучшей интернет библиотеки ЛибКинг или прочесть краткое содержание (суть), предисловие и аннотацию. Так же сможете купить и скачать торрент в электронном формате fb2, найти и слушать аудиокнигу на русском языке или узнать сколько частей в серии и всего страниц в публикации. Читателям доступно смотреть обложку, картинки, описание и отзывы (комментарии) о произведении.
  • Название:
    Руководство по DevOps
  • Автор:
  • Жанр:
  • Издательство:
    Манн, Иванов и Фербер
  • Год:
    2018
  • Город:
    Москва
  • ISBN:
    9785001007500
  • Рейтинг:
    2.5/5. Голосов: 21
  • Избранное:
    Добавить в избранное
  • Отзывы:
  • Ваша оценка:
    • 60
    • 1
    • 2
    • 3
    • 4
    • 5

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

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

Руководство по DevOps - читать онлайн бесплатно ознакомительный отрывок

Руководство по DevOps - читать книгу онлайн бесплатно (ознакомительный отрывок), автор Джин Ким
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

56

Черная пятница — пятница после Дня благодарения в США. С нее начинается традиционный рождественский сезон распродаж. Прим. перев.

57

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

58

Эрнест Мюллер отмечал: «В компании Bazaarvoice существовало соглашение, что эти платформенные команды принимают от других команд требования на создание инструментов, но не принимают задания на выполнение работы». Прим. авт.

59

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

60

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

61

Scrum — это методология разработки по системе Agile, описываемая как «гибкий, целостный продукт стратегии разработки, при которой команда разработчиков работает как единое целое для достижения общей цели». Она была впервые полностью описана Кеном Швабером и Майком Бидлом в книге Agile Software Development with Scrum. В этой книге мы используем термины «разработка Agile» или «итеративная разработка», чтобы охватить различные методы, использующиеся специальными методологиями, такими как Agile и Scrum. Прим. авт.

62

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

63

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

64

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

65

Первой системой контроля версий была, скорее всего, UPDATE для CDC6600 (1969). Позднее появились SCCS (1972), CMS для VMS (1978), RCS (1982) и так далее. Прим. авт.

66

Можно видеть, что система контроля версий выполняет некоторые из ITIL-конструкций Definitive Media Library (DML) и Configuration Management Database (CMDB), инвентаризируя все необходимое для повторного создания производственной среды. Прим. авт.

67

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

68

Любой, кто выполнял миграцию кода для системы ERP (например, SAP, Oracle Financials и так далее), знаком со следующей ситуацией: когда миграция кода дает сбой, причиной редко бывает ошибка в коде. Намного более вероятно, что миграция не удалась ввиду неких различий в средах, например между средами, использующимися разработчиками и тестировщиками, или тестовой средой и производственной. Прим. авт.

69

В компании Netflix средний возраст копий Netflix AWS составляет 24 дня, при том что 60 % из них имеют возраст менее недели. Прим. авт.

70

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

71

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

72

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

73

Блэнд описывал, что одним из последствий такого большого числа талантливых разработчиков в компании Google стало появление у них «синдрома самозванца». Этот термин был введен психологами, чтобы неформально описать людей, которые не в состоянии глубоко осознать свои же достижения. В Википедии этот термин описывается так: «Несмотря на внешние доказательства состоятельности, подверженные этому синдрому продолжают считать, что они обманщики и не заслуживают успеха, которого достигли. Успехи они, как правило, объясняют удачей, попаданием в нужное место и время или введением других в заблуждение, будто они умнее и компетентнее, чем есть на самом деле». Прим. авт.

74

Они создали обучающие программы, распространявшиеся через известный информационный бюллетень Testing on the Toilet (который они развешивали в санитарных комнатах), план работы и сертификационную программу Test Certified и провели несколько собраний fix-it («исправь это»), которые помогли командам улучшить автоматическое тестирование процессов, с тем чтобы они смогли воспроизвести потрясающие результаты, которых сумела добиться команда GWS. Прим. авт.

75

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

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

Интервал:

Закладка:

Сделать


Джин Ким читать все книги автора по порядку

Джин Ким - все книги автора в одном месте читать по порядку полные версии на сайте онлайн библиотеки LibKing.




Руководство по DevOps отзывы


Отзывы читателей о книге Руководство по DevOps, автор: Джин Ким. Читайте комментарии и мнения людей о произведении.


Понравилась книга? Поделитесь впечатлениями - оставьте Ваш отзыв или расскажите друзьям

Напишите свой комментарий
x