[Перевод] Как стать DevOps инженером за полгода или даже быстрее. Часть 3. Версии10.05.2020 21:07

Как стать DevOps инженером за полгода или даже быстрее. Часть 1. Введение
Как стать DevOps инженером за полгода или даже быстрее. Часть 2. Конфигурирование

Освежим память

В первой части мы говорили о культуре и целях DevOps, во второй — о том, как заложить основу для будущих развертываний кода с помощью Terraform, который сам является кодом. В третьей части мы обсудим, как уберечь все эти части кода от полного беспорядка. Спойлер: это все из-за Git!

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

Зачем об этом беспокоиться?

Что имеется в виду под управлением версиями (versioning)? Представьте, что вы работаете над каким-то программным обеспечением и постоянно вносите в него изменения, добавляя или удаляя функции по мере необходимости. Часто последнее изменение будет фундаментальным изменением, ломающим все созданное ранее. Если вы представитель старой школы, то наверняка назовете свой первый файл awesome_code.p1.

Затем вы начинаете вносить изменения, и вам нужно сохранить то, что работает, на случай, если придется к нему вернуться. Поэтому вы переименовываете свой файл на такой: awesome_code.12.25.2018.p1.

Все работает прекрасно до тех пор, когда в один и тот же день вы не сделаете несколько изменений, и вам придется назвать новый файл awesome_code.GOOD.12.25.2018.p1. И продолжаете в том же духе.

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

Система управления версиями Source Code Control

Используйте систему управления версиями SCC — это способ сохранить ваши файлы в централизованном месте, в котором несколько команд могут совместно работать над общей кодовой базой. Эта идея не нова. Самое раннее упоминание о системе SCC, которое мне удалось найти, относится к 1972 году. Таким образом, идея о том, что мы должны централизовать наш код в одном месте, определенно устарела.

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

Более того, применение закона «все артефакты prod должны быть версионными» действительно заставляет вас подходить к проблемам по принципу «автоматизация прежде всего».

Например, когда вы решаете просто кликнуть по сложной проблеме в своей среде разработки AWS, вы можете сделать паузу и подумать: «является ли это кликом по версионному артефакту»? Конечно, ответ будет «нет».

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

Репозиторий Git

До появления Git использование SCCS, таких как SVN, было неуклюжим, не удобным для пользователя и в целом довольно болезненным опытом. Отличие Git в том, что он обеспечивает распределенное управление версиями. Проще говоря, вы не блокируете других пользователей централизованного хранилища исходного кода, пока работаете над своими изменениями, а работаете с полной копией кодовой базы. После того, как вы закончите свою работу, эта копия будет внедрена в главный репозиторий Master repository.

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

Пока что просто запомните, что Git работает не так, как SVN. Это распределенная система управления исходным кодом (версиями), в которой несколько команд разработчиков могут безопасно и надежно работать над общей кодовой базой.

Зачем это нужно знать?

Я решительно утверждаю, что, не зная, как работает Git, вам никогда не стать профессиональным инженером DevOps (Cloud). Как же его изучить? Замечу, что результат поиска в Google по запросу «Учебник Git» обычно выдает ссылки на чрезвычайно раздутые и запутанные пособия. Тем не менее, среди них попадаются несколько действительно толковых учебников.

Одна из таких серий учебников, которые я всем рекомендую прочитать, изучить и использовать на практике, это Atlassian«s Git Tutorials. Все они достаточно хороши, но один раздел, Git Workflows, описывающий рабочие процессы этого репозитория, используется профессиональными программистами во всем мире.

Еще один действительно хороший учебник — это изучение ветвления репозитория Learn Git Branching. Atlassian tutorials построен по принципу «прочти и выучи», а Learn Git Branching представляет собой интерактивный учебник. В любом случае, вы не продвинетесь далеко в изучении DevOps, если не поймете, как работает этот репозиторий.

Замечу, что отсутствие понимания того, как работает функция Git Branching или неспособность объяснить, что такое Gitflow, топит во время собеседования 99% претендентов на кандидатуру инженера-разработчика DevOps. Это ключевой момент — вы можете прийти на собеседование и не знать Terraform или какой-либо другой новейший модный инструмент infrastructure-as-code, и это нормально, потому что вы можете изучить его в процессе работы. Но незнание работы Git свидетельствует о том, что вам не хватает основ современных передовых практик разработки программного обеспечения, не важно, касается ли это DevOps или нет. Это сигнализирует менеджерам по найму, что ваша кривая обучения слишком неровная.

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

создать копию репозитория (Fork a repo);
cоздать ветвление Git;
синхронизировать поток к репозиторию и обратно;
создать запрос Pull Request.

Что дальше?

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

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

Примечание: при изучении использования git+GitHub обратите особое внимание на Pull Request (или PRs, если вы хотите быть крутым).

Бренд

Кстати о крутизне: собственный бренд — это способ продемонстрировать всему миру, на что вы способны. Один из способов (в настоящее время это один из лучших способов!) заключается в том, чтобы прочно привязать GitHub в качестве прокси для вашего бренда. Почти все работодатели в наши дни так или иначе попросят об этом. Поэтому вы должны стремиться иметь аккуратный, тщательно курируемый аккаунт на GitHub. Это то, что вы можете поместить в свое резюме и чем можете гордиться.

В следующих статьях я расскажу, как создать простой, но классный сайт на GitHub с использованием генератора статических сайтов Hugo. Он написан на Go, и, пожалуй, на сегодня является самым быстрым среди аналогов. Hugo собирает около 5000 страниц за 6 секунд, что в 75 раз больше скорости Middleman. Но вам пока что достаточно просто поместить свой код в GitHub.
Позже, когда вы наберетесь опыта, стоит подумать о том, чтобы иметь две учетные записи GitHub. Одну для хранения собственноручно написанного прикладного, рабочего кода, а другую — для хранения кода, который вы хотите показать другим.

Итак, просуммируем вышесказанное:

изучайте Git;
размещайте на GitHub все, чему вы научились;
задействуйте два аккаунта для хранения и демонстрации всего, чему вы научились
получите от этого выгоду!

Выводы

Будьте в курсе последних разработок в этой области, таких, как GitOps. GitOps выводит все идеи, которые мы обсуждали до сих пор, на новый уровень, где все делается с помощью git, pull-запросов и конвейеров развертывания.

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

Продолжение будет совсем скоро…

Немного рекламы :)

Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5–2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5–2697v3 2.6GHz 14C 64GB DDR4 4×960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5–2430 2.2Ghz 6C 128GB DDR3 2×960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5–2650 v4 стоимостью 9000 евро за копейки?