В предыдущих статьях мы разобрались, c Linux и Bash.
Следующая ступенька — Git.
На первый взгляд может показаться, что Git нужен только программистам. Ведь именно разработчики постоянно пишут код, исправляют ошибки и добавляют новые функции.
На самом деле сегодня Git используют практически все инженеры, работающие с инфраструктурой. В Git хранят не только исходный код приложений, но и Dockerfile, Kubernetes-манифесты, Terraform-конфигурации, Ansible Playbook, Bash-скрипты и CI/CD-конвейеры.
Фактически Git стал центральной точкой любого современного проекта.
Но чтобы понять, почему он настолько важен, сначала стоит разобраться, какие проблемы он решает.
Как работали без Git?
Представьте небольшую команду из двух разработчиков. Оба работают над одним проектом. Первый изменяет файл:
config.yaml
Через несколько минут второй меняет этот же файл.
Теперь возникает вопрос:
Какая версия правильная?
Если файл просто переслать через мессенджер или заменить на сервере, одна из версий будет потеряна.
Именно поэтому раньше проекты могли выглядеть примерно так:
project_final.zipproject_final2.zipproject_final_new.zipproject_final_final.zipproject_final_final_REAL.zip
Наверняка многие хотя бы раз сталкивались с подобной ситуацией. Со временем проекты стали больше, команды стали больше, а подобный способ хранения файлов перестал работать.
Понадобилась система, которая могла бы:
-
хранить историю изменений;
-
показывать, кто и когда изменил файл;
-
объединять изменения нескольких разработчиков;
-
возвращаться к любой предыдущей версии проекта.
Так появились системы контроля версий.
Что такое система контроля версий?
Система контроля версий (Version Control System, VCS) — это программа, которая сохраняет историю изменений файлов.
Представьте себе функцию «Отменить» в текстовом редакторе.
Теперь представьте, что она:
-
работает месяцами;
-
запоминает каждое изменение;
-
знает, кто его сделал;
-
позволяет вернуться к любой версии проекта.
Именно этим и занимается Git. Каждое изменение фиксируется и становится частью истории проекта. Даже если через полгода окажется, что новая версия содержит ошибку, можно посмотреть, когда она появилась, и восстановить рабочее состояние.
Почему именно Git?
До Git существовали и другие системы контроля версий.
-
CVS;
-
Subversion (SVN);
-
Mercurial.
Однако в 2005 году создателю Linux, Линусу Торвальдсу, при разработке ядра Linux, понадобилась VCS и ввиду определенных обстоятельств, использовать другие не представлялось возможным. И было решено разработать собственную систему контроля версий, названную Git.
Главная идея Git заключалась в том, чтобы сделать работу быстрой, распределённой и независимой от центрального сервера.Именно благодаря этим особенностям Git постепенно стал отраслевым стандартом.
Сегодня его используют практически все современные проекты — от небольших стартапов до крупнейших IT-компаний.
Git и GitHub — это одно и то же?
Это одно из самых распространённых заблуждений.
Нет.
Git — программа, которая устанавливается на компьютер и управляет историей изменений.
GitHub — онлайн-сервис, где можно хранить Git-репозитории. Помимо хранения репозиториев GitHub умеет автоматически выполнять различные действия при изменении проекта. Эта возможность называется GitHub Actions.
Например, после каждого git push GitHub может:
-
проверить, что проект успешно собирается;
-
запустить автоматические тесты;
-
проверить форматирование кода;
-
собрать Docker-образ;
-
развернуть новую версию приложения на сервере или в Kubernetes.
Благодаря этому GitHub становится не только местом хранения кода, но и инструментом автоматизации разработки.
Однако Git прекрасно работает без GitHub.
Можно создать локальный репозиторий и никогда не публиковать его в интернете. Однако при командной работе GitHub значительно упрощает совместную разработку. Кроме GitHub существуют и другие платформы:
-
GitLab;
-
Bitbucket;
-
Azure DevOps.
Все они используют Git как основу.
Что такое репозиторий?
Практически сразу после знакомства с Git появляется новый термин — репозиторий.
Репозиторий (Repository) — это каталог проекта вместе со всей историей изменений.
Внутри находятся:
-
исходный код;
-
конфигурационные файлы;
-
изображения;
-
документация;
-
история всех изменений.
Когда вы создаёте Git-репозиторий, Git начинает отслеживать состояние файлов. С этого момента можно в любой момент узнать:
-
какие файлы изменились;
-
какие были удалены;
-
какие появились впервые.
Что такое удалённый репозиторий?
Репозиторий, хранящийся на вашем компьютере называется локальным.
Однако если компьютер сломается или вы захотите продолжить работу с другого устройства, возникнут проблемы. Поэтому проект обычно хранится ещё и на удалённом сервере.
Такой репозиторий называется удалённым (Remote Repository). Именно его обычно размещают на GitHub.
Благодаря этому каждый участник команды работает со своей копией проекта, а GitHub становится общей точкой обмена изменениями.
Что такое коммит?
Коммит (Commit) — это снимок проекта в определённый момент времени. Важно понимать, что Git хранит не просто файлы.
Он хранит всю историю развития проекта. Поэтому можно легко ответить на вопросы:
-
кто изменил файл;
-
когда это произошло;
Хорошее сообщение коммита выглядит так:
Заменил "что-то"Исправил "такую-то" ошибку
Что такое ветки?
Представим ситуацию.
Вы хотите добавить новую функцию. Но не уверены, что она будет работать правильно. Изменять основную версию проекта рискованно.
Для этого Git предлагает использовать ветки (Branches).
Ветка — это независимая линия разработки. Можно экспериментировать сколько угодно. Если всё получилось — изменения объединяются с основной веткой. Если эксперимент оказался неудачным — ветку можно просто удалить.
Именно благодаря веткам несколько разработчиков могут одновременно работать над разными функциями, практически не мешая друг другу.
Что такое Pull Request?
Представим, что разработчик закончил работу над новой функцией в своей ветке. Можно ли сразу объединить её с основной веткой проекта?
Технически — да.
Но в командной разработке так почти никогда не делают.
Вместо этого создаётся Pull Request (PR) — запрос на объединение изменений с основной веткой. Pull Request позволяет другим участникам команды проверить изменения до того, как они станут частью проекта.
Во время проверки можно:
-
оставить комментарии к коду;
-
предложить исправления;
-
обсудить архитектурные решения;
-
запустить тесты;
-
убедиться, что изменения не нарушили работу проекта.
Только после успешной проверки Pull Request объединяется с основной веткой. Благодаря этому вероятность ошибок значительно снижается.
Почему недостаточно одного только Git?
Представьте небольшую команду из пяти человек. Разработчики создают новые функции. Тестировщики находят ошибки. DevOps настраивает CI/CD.
Менеджер планирует следующий релиз. Возникает несколько вопросов:
-
Какие задачи уже выполнены?
-
Какие находятся в работе?
-
Какие ошибки самые критичные?
-
Что войдёт в следующую версию приложения?
Git отвечает только на один вопрос:
Как изменился код?
Но он не знает, почему были внесены изменения, кто их запросил и когда они должны попасть в релиз.
Именно здесь начинают работать инструменты управления проектом.
GitHub Issues — задачи, идеи и ошибки
Issue — это карточка, в которой описывается конкретная задача.
Это может быть:
-
ошибка (Bug);
-
новая возможность (Feature);
-
предложение по улучшению;
-
вопрос по документации.
Например:
Title:Добавить HTTPS для NginxDescription:Необходимо настроить автоматическое получение TLS-сертификатов через Let's Encrypt.
Или:
Title:Ошибка авторизации после обновления...
Каждая задача получает уникальный номер.
Например:
#125
Благодаря этому можно написать в сообщении коммита:
Fix #125
или
Closes #125
После слияния изменений GitHub автоматически закроет соответствующую задачу. Так связываются код и причина его появления.
Что обычно содержит Issue?
Хорошо оформленная задача обычно включает:
-
краткий заголовок;
-
подробное описание;
-
ожидаемый результат;
-
фактическое поведение;
-
шаги воспроизведения ошибки;
-
приоритет;
-
исполнителя;
-
метки (Labels).
GitHub Projects — доска задач
Когда задач становится много, обычного списка уже недостаточно.
Для этого существуют Projects. Projects — это инструмент для визуального управления задачами.
Наиболее распространённый вариант — Kanban-доска.
Она может выглядеть так:
Или так
Каждая задача представляет собой карточку, которая постепенно перемещается между колонками. Так вся команда сразу понимает текущее состояние проекта.
Что такое Milestones?
Представьте, что команда планирует выпустить новую версию приложения через месяц. В неё должны войти:
-
новая авторизация;
-
поддержка HTTPS;
-
оптимизация базы данных;
-
исправление десяти ошибок.
Все эти задачи можно объединить в один Milestone. Milestone — это набор задач, которые необходимо завершить к определённой дате.
GitHub автоматически показывает прогресс их выполнения.
Например:
65 %
Releases — выпуск новой версии
Когда работа завершена, проект получает новую версию.
Именно для этого используется Release.
Release — это опубликованная версия проекта, которую можно скачать и использовать.
Например:
v1.0.0
Каждый Release обычно содержит:
-
номер версии;
-
дату выпуска;
-
список изменений;
-
исправленные ошибки;
-
новые возможности.
Такой список называется Release Notes.
Например:
Что нового в версии 2.0• Добавлена авторизация через OAuth• Добавлена поддержка HTTPS• Исправлена ошибка загрузки изображений• Улучшена производительность API
Это позволяет пользователям быстро понять, что изменилось после обновления.
Как всё связано между собой?
Рассмотрим типичный рабочий процесс. Сначала появляется задача.
Issue
Она попадает в общий план работ.
Project
Если задача относится к определённой версии продукта, её добавляют в:
Milestone
После выполнения разработчик отправляет изменения через Pull Request. После проверки код объединяется с основной веткой.
Как GitHub использует DevOps?
Хотя многие считают Issues и Projects инструментами менеджеров, DevOps тоже активно работает с ними.
Например, задачи DevOps могут выглядеть так:
-
внедрить мониторинг;
-
настроить резервное копирование;
-
автоматизировать сборку Docker-образов;
-
обновить Terraform-конфигурации;
Все эти изменения проходят тот же процесс планирования, проверки и выпуска, что и разработка новых функций.
Базовый цикл работы с Git
Практически любой рабочий день разработчика или DevOps выглядит примерно одинаково.
-
Получить последнюю версию проекта.
-
Внести изменения.
-
Проверить результат.
-
Зафиксировать изменения.
-
Отправить их в удалённый репозиторий.
В Git это выглядит следующим образом:
git pullgit statusgit add .git commit -m "Добавить резервное копирование"git push
Разберём каждую команду.
git pull
Получает последние изменения из удалённого репозитория и объединяет их с вашей локальной копией. Перед началом работы рекомендуется убедиться, что вы работаете с актуальной версией проекта.
git status
Показывает текущее состояние репозитория:
-
какие файлы изменены;
-
какие ещё не отслеживаются;
-
какие готовы к коммиту.
Это одна из самых часто используемых команд Git.
git add
Добавляет изменения в индекс (staging area) — специальную промежуточную область перед созданием коммита. Это позволяет выбрать, какие изменения войдут в следующий коммит, а какие пока останутся вне его.
Например:
git add README.md
добавит только один файл. А
git add
добавит все изменения в текущем каталоге.
git commit
Создаёт новый коммит. Именно после этой команды изменения попадают в историю проекта.
git push
Отправляет локальные коммиты в удалённый репозиторий, например на GitHub.
После этого изменения становятся доступны другим участникам команды.
После знакомства с Git и GitHub у многих новичков возникает закономерный вопрос.
«Если Git — это система контроля версий, зачем он нужен DevOps? Ведь DevOps почти не пишет код.»
Ответ может показаться неожиданным.
Во многих компаниях в Git находится практически вся инфраструктура проекта:
-
конфигурации серверов;
-
Dockerfile;
-
Docker Compose;
-
Kubernetes-манифесты;
-
Terraform-конфигурации;
-
Ansible Playbook;
-
CI/CD-конвейеры;
-
документация;
-
инструкции по развертыванию.
Почему перестали настраивать серверы вручную?
Представьте небольшую компанию. Есть один сервер.
Администратор подключается по SSH и вручную выполняет команды.
sudo apt install nginx
Создаёт пользователя.
sudo adduser devops1
Затем меняет конфигурацию и перезапускает сервис. Всё работает.
Теперь представьте другую ситуацию. У компании уже сто серверов. Можно ли выполнить эти действия вручную?
Технически — да.
Практически — нет.
Во-первых, это долго. Во-вторых, легко ошибиться.
Именно поэтому современный DevOps старается описывать инфраструктуру обычными текстовыми файлами. А текстовые файлы лучше всего хранить именно в Git.
Infrastructure as Code
Здесь появляется один из самых важных терминов современной DevOps-культуры.
Infrastructure as Code (IaC) — «Инфраструктура как код».
Суть идеи очень простая.
Вместо ручной настройки серверов инженер описывает желаемое состояние инфраструктуры в виде файлов. Например:
вместо инструкции
«Установите Docker, затем откройте порт 80, затем создайте пользователя…»
появляется файл конфигурации. Именно он становится источником истины.
Если необходимо создать ещё один сервер, не нужно вспоминать последовательность команд. Достаточно выполнить конфигурацию. Получится абсолютно одинаковый результат.
Это делает инфраструктуру:
-
воспроизводимой;
-
документированной;
-
проверяемой;
-
удобной для совместной работы.
Git как единственный источник истины
В современной GitOps часто используют выражение:
Git is the Single Source of Truth.
То есть именно репозиторий считается правильным описанием инфраструктуры. Если сервер отличается от конфигурации в Git — значит, проблема на сервере.
Не наоборот.
Это позволяет быстро восстанавливать инфраструктуру после сбоев. Например, новый сервер можно создать автоматически, используя те же самые конфигурационные файлы.
Что такое GitOps?
Следующий этап развития этой идеи получил название GitOps.
Если Infrastructure as Code отвечает на вопрос:
«Как описывать инфраструктуру?»
то GitOps отвечает:
«Как автоматически применять эти изменения?»
Основная идея GitOps выглядит очень просто.
В идеальной модели GitOps инженер не изменяет инфраструктуру напрямую на сервере. Все изменения проходят через Git и автоматически применяются системой доставки.
Например:
replicas: 3
заменяет на
replicas: 5
Создаёт коммит. Отправляет изменения на GitHub. После этого специальная система автоматически замечает новые изменения и применяет их к инфраструктуре.
Во многих проектах первым этапом становится запуск GitHub Actions. Они проверяют изменения, выполняют тесты и убеждаются, что конфигурация не содержит ошибок. Только после успешной проверки изменения становятся доступны системам GitOps, таким как Argo CD или Flux, которые применяют их к инфраструктуре.
Человек больше не подключается к серверу вручную. Все изменения проходят через Git.
Почему GitOps считается более безопасным и надежным?
Представим ситуацию. Инженер случайно удалил настройки Kubernetes прямо на сервере. Восстановить будет довольно затруднительно.
Если же используется GitOps, достаточно открыть историю Git. При необходимости можно выполнить откат буквально к любому коммиту.
Способ изучения Git
Способ довольно простой.
С самого начала любого проекта, начинайте использовать Git.
К примеру:
-
Создайте репозиторий с простым проектом.
-
Добавьте несколько Issues: исправление ошибки, новая функция.
-
Создайте Project с колонками To Do, In Progress и Done.
-
Объедините задачи в Milestone с названием
v1.0. -
После завершения задач создайте Release с краткими Release Notes.
Такое упражнение позволит понять не только работу GitHub, но и общий жизненный цикл разработки программного обеспечения.
Что дальше?
Мы познакомились с основными понятиями Git и GitHub. В следующей статье перейдем к Docker
ссылка на оригинал статьи https://habr.com/ru/articles/1058380/