- Оригинальный адрес:How To Become a DevOps Engineer In Six Months or Less, Part 3: Version
- Оригинальный автор:Igor Kantor
- Перевод с:Программа перевода самородков
- Постоянная ссылка на эту статью:GitHub.com/rare earth/gold-no…
- Переводчик:jianboy
- Корректор:lihanxiang
Примечание. Это третья часть серии «Как стать инженером DevOps за шесть месяцев или меньше». Нажмите здесь, чтобы просмотреть первую часть.здесь. Щелчок второй частиздесь.
Давайте сделаем краткий обзор предыдущей проблемы.
Короче говоря, эта серия статей рассказывает историю.
И эта история учит быстро превращать идеи в деньги — квинтэссенция современной DevOps-разработки.
В частности, впервая частьМы говорили о культуре и целях DevOps.
существуетВторая часть, мы обсудили, как использовать Terraform, чтобы заложить основу для будущих развертываний кода. Конечно, Terraform — это тоже код!
Итак, в этом посте мы собираемся обсудить, как предотвратить полный выход из-под контроля всего этого кода. Спойлер, это все оgit!
Бонус: мы также обсудим, как использовать этот git-бизнес для создания и продвижения вашего личного бренда.
Для справки, мы начинаем здесь:
Путь DevOps
Итак, когда мы говорим о «контроле версии», о чем мы говорим?
Представьте, что вы разрабатываете какое-то программное обеспечение. Вы постоянно меняете его, добавляя или удаляя функции по мере необходимости. Как правило, последнее изменение будет «критическим». Другими словами, что бы вы ни делали, это разрушает предыдущую работу.
что делать?
хорошо. Если вы были в предыдущей школе, вы могли бы назвать свой первый файл:
awesome_code.pl
Затем вы начинаете вносить некоторые изменения в файл, и вам нужно сохранить что-то полезное на случай, если вам придется его восстановить.
Итак, вы переименовываете файл в:
awesome_code.12.25.2018.pl
Это хорошо. Пока однажды вы не вносите несколько изменений в день, так что в итоге вы получите что-то вроде этого:
awesome_code.GOOD.12.25.2018.pl
и Т. Д.
Конечно, в профессиональной среде у вас есть несколько команд, работающих над одной и той же кодовой базой, что еще больше нарушает эту схему резервного копирования документов.
Излишне говорить, что описанное выше переименование файлов для управления версиями точно не сработает.
Контроль версий: способ сохранить файлыконцентрированныйПодход к местам, где несколько команд могут работать вместе над общей кодовой базой.
Идея не нова. Самое раннее упоминание, которое я смог найтистатьяДатируется 1972 годом! Так что идея, что мы должны централизовать наш код в одном месте, определенно устарела.
Однако относительно новым являетсяВсе процессы разработки должны быть версионнымиидея.
Что это обозначает?
Это означает, что все, что связано с производственной средой, должно храниться в системе контроля версий и подлежать отслеживанию, аудиту и записи исторических изменений.
Также, соблюдая принцип, что «все процессы развития должны быть версированы», на самом деле заставляет вас подходить к проблемам с проблемами «автоматизации».
Например, когда вы решаете, что можете сделать паузу и подумать над этим вопросом в среде DEV AWS: «Все операции кликов контролируются версией?»
Конечно, ответ «нет». Таким образом, несмотря на то, что быстрое прототипирование через пользовательский интерфейс можно проверить, работает ли оно, эти усилия должны быть недолгими. В долгосрочной перспективе убедитесь, что все, что вы делаете с Terraform или другими инструментами архитектуры как кода, контролируется версиями.
Итак, если все находится под контролем версий, как мы будем хранить и управлять этим материалом?
Ответ - гит.
существуетgitДо того, как это появилось, использование системы контроля версий, такой как SVN или других, было неуклюжим, неудобным для пользователя и часто было очень болезненным опытом.
git отличается тем, что содержитраспределенныйКонцепция контроля исходного кода.
Другими словами, вы не блокируете доступ других к централизованному репозиторию исходного кода, пока работаете над изменениями. Вместо этого вы пишете полныйкопировать. Тогда копия будетmergedВходитьmasterРепозиторий.
Помните, что это грубые упрощение для Git, как это работает. Но с точки зрения этой статьи было достаточно, даже если они знают внутреннюю работу git ценным и занять некоторое время для освоения.
Теперь помните этого мерзавцанетКак и старые версии SVN. Это распределенная система управления версиями, в которой несколько команд могут безопасно и надежно работать над общей кодовой базой.
Что это значит для нас?
В частности, я серьезно сомневаюсь в вашей способности называть себя профессиональным DevOps (облачным) инженером без использования управления версиями git. Это так просто.
Итак, как изучить git?
Я должен сказать, что разница между гуглением «git tutorial» заключается в том, что он предоставляет очень подробные, но очень запутанные руководства.
Однако есть очень и очень хорошие.
Серия руководств, которые я рекомендую всем прочитать, изучить и попрактиковаться,Учебники Atlassian по Git.
На самом деле, все они довольно хороши, но особенно та часть, которую используют профессиональные программисты по всему миру:Git Workflows.
Я не могу не подчеркнуть это достаточно. Снова и снова отсутствие понимания того, как работают ветки git, или объяснения того, что такое Gitflow, останавливает 99% начинающих инженеров DevOps.
Это ключ. Вы можете давать интервью, даже если вы не знаете Terraform или новейшую архитектуру и код, это нормально — вы можете изучить это на работе.
Незнание git и того, как он работает, показывает, что вам не хватает основ современных передовых методов разработки программного обеспечения, DevOps или нет. Это сигнализирует менеджерам по найму, что у вас очень крутая кривая обучения. Вы не хотите сигнализировать!
Вместо этого ваша способность уверенно говорить о лучших практиках git говорит менеджерам по найму, что вам нужно в первую очередь иметь мышление инженера-программиста — то мышление, которое вы хотите применять в своей работе.
В общем, вам не нужно быть ведущим экспертом по git в мире, чтобы получить потрясающую роль DevOps, но вам нужно какое-то время жить и дышать git, чтобы иметь возможность уверенно говорить о том, что происходит.
Как минимум, вы должны владеть следующими навыками:
- Разветвить репозиторий
- создать ветку
- Объединить два разных коммита
- Создать запрос на включение
Теперь, когда вы ознакомились с вводным руководством по git, получитеGitHubСчет.
Примечание. GitLab тоже работает, но на момент написания этой статьи GitHub является самым популярным git-репозиторием с открытым исходным кодом, так что вам определенно захочется поделиться им с другими.
Как только вы получите учетную запись GitHub, начните вносить в нее код! Все, что вы изучаете, требует от вас написания кода, регулярно публикуйте его на GitHub.
Это не только привьет хорошие идеи управления исходным кодом, но и поможет вам создать свой личный бренд.
Примечание. Обратите особое внимание, когда узнаете, как использовать git + GitHub.Pull Requests(Также называется PR, если хотите быть крутым).
Pull Request, by Vidar Nordli-Mathisen
Брендинг: способ продемонстрировать свои возможности всему миру.
Таким образом (в настоящее время это один из лучших способов!) нужно настроить учетную запись GitHub для представления вашего бренда. Почти все интервьюеры в наши дни требуют от кандидатов наличия учетной записи GitHub.
Так что вы должны стремиться к тому, чтобы у вас была опрятная, хорошо курируемая учетная запись GitHub, которую вы могли бы добавить в свое резюме и которой можно гордиться.
В следующем разделе мы обсудим, как использоватьHugoФреймворк создает простой, но классный веб-сайт на GitHub. Теперь просто поместите код в GitHub.
Позже, как вы становитесь более опытными, вы можете рассмотреть возможность использования двух учетных записей GitHub. Один профиль для тренировочного кода, который вы пишете, а другой для кода, который вы хотите показать другим.
в заключении:
- выучить git
- Делитесь всем, что вы узнали, с GitHub
- Используйте № 1 и № 2 в качестве демонстрации всего, что вы узнали на данный момент.
- Польза от!
Наконец, имейте в виду последние разработки в этой области, такие какGitOps.
GitOps выводит все идеи, которые мы обсуждали до сих пор, на новый уровень — все через git, запросы на вытягивание и конвейерные развертывания.
Обратите внимание, что GitOps и подобные инструменты должныБизнесаспекты вещей. В частности, мы не используем такие сложные вещи, как git, потому что они крутые.
Вместо этого мы используем git для обеспечения гибкости бизнеса, ускорения инноваций и более быстрого предоставления функций — все это в конечном итоге делает наш бизнес более прибыльным!
Это все на данный момент!
Если вы обнаружите ошибки в переводе или в других областях, требующих доработки, добро пожаловать наПрограмма перевода самородковВы также можете получить соответствующие бонусные баллы за доработку перевода и PR. начало статьиПостоянная ссылка на эту статьюЭто ссылка MarkDown этой статьи на GitHub.
Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,продукт,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.