Вернуться к главной странице, списку всех тем

3. Управление версиями проектов, автоматизация при внесении изменений

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

Основные задачи Git

• Отслеживание изменений: Каждый раз, когда вы вносите изменения в проект, Git запоминает их, создавая так называемую «версию» или «коммит». Это позволяет вернуться к любой предыдущей версии кода, если вдруг понадобится откатиться назад.
  • История изменений: Git хранит всю историю изменений, включая комментарии о том, почему были внесены те или иные правки. Это помогает понять, что именно было сделано и кем.
• Совместная работа: Несколько разработчиков могут одновременно работать над одним проектом, вносить свои изменения и затем объединять их через Git, решая все расхождения. Например, если они редактировали один и тот же текстовый файл, они выбирают, чьи коммиты в итоге останутся. Это особенно полезно для больших команд, где важно координировать работу разных людей.
  • Управление ветками: Ветка (branch) — это отдельная линия разработки проекта. Например, одна команда может работать над новой функцией в отдельной ветке, а другая — исправлять баги в основной ветке программы. Когда всё готово, ветка, где разработчики работали над новой функцией, вливается в основную ветку.

Основные понятия Git

1. Репозиторий — это каталог, в котором хранятся все файлы проекта и история их изменений. Git хранит эту историю и настройки в репозитории в специальной директории .git.
2. Коммит — это зафиксированные изменения с описанием того, что было сделано.
3. Ветка — это отдельная линия разработки, позволяющая работать над проектом независимо от основной линии.
4. Слияние (merge) — это процесс объединения изменений из одной ветви в другую.
5. Конфликт — это ситуация, когда два разработчика вносят изменения в один и тот же файл, и необходимо решить, чьи изменения оставить.
6. Клонирование — это создание локальной копии удаленного репозитория.
7. GitHub — это онлайн-платформа, которая предлагает удобный способ хранения репозиториев.
8. Push/Pull — это операции отправки и получения изменений с удаленного сервера репозитория, например GitHub.
9. Tag — это метка, которая отмечает важные события в проекте, такие как выпуск версии. Tag аналогичен ветке, но в него нельзя вносить изменения.

GitHub

GitHub — это онлайн-платформа для хранения кода и совместной работы над программными проектами с использованием Git. Представь себе огромный склад, где программисты могут хранить свои git-репозитории, делиться ими с другими людьми и вместе работать над ними.

Например, это обучение размещено на GitHub в виде репозитория: github.com/eabykov/devops-v2

CI/CD автоматизация

Представьте, что вы строите дом на колёсах:

• CI - каждый член вашей команды выполняет свою часть работы: кто-то возводит стены, кто-то устанавливает окна, а кто-то занимается электропроводкой. В конце дня вы хотите увидеть, насколько хорошо все части дома сочетаются друг с другом.
• СI - Теперь представьте, что после завершения строительства вы проверяете, всё ли сделано правильно: работают ли окна, нет ли трещин в стенах и исправен ли свет. Это тестирование.
• CD - Когда проверка завершена, вы готовы отправить готовый дом его владельцам. Это процесс доставки или развёртывания.

CI/CD помогает сделать этот процесс для программ более быстрым и автоматическим, избавляя от необходимости ждать, пока кто-то вручную выполнит каждую задачу (например, команду в терминале или тестирование). Автоматизированная последовательность шагов называется пайплайн (pipeline).

На таких платформах, как GitHub и GitLab (по сути, это та же GitHub, только с возможностью установки на свой сервер и создания собственной онлайн-платформы, им пользуются большинство корпораций, т.к. хотят хранить свой код не в GitHub, а у себя на сервере), вы можете автоматизировать разные сценарии при разных событиях в Git-репозитории:

• коммит
• коммит в конкретную ветку
• слияние
• выпуск тега
• расписанию

В результате этих событий могут автоматически происходить различные шаги непрерывной интеграции и доставки (CI/CD), среди которых:

1. CI Сборка проекта: Когда вы отправляете изменения в репозиторий, проект автоматически собирается, чтобы убедиться в правильности работы после ваших нововведений. Сборка проекта — это процесс преобразования исходного кода, написанного программистом, в исполняемый файл, который компьютер может понять и запустить. Это можно сравнить с рецептом блюда на бумаге: чтобы приготовить само блюдо, необходимо следовать этому рецепту и использовать необходимые ингредиенты. Исходный код — это и есть тот самый рецепт, а готовая программа — уже приготовленное блюдо.
2. CI Тестирование: После успешной сборки проект может запускать тесты, чтобы проверить, нет ли ошибок в коде, запускается ли программа и работает ли она так, как ожидалось.
3. CD Публикация: Если все тесты пройдены успешно, ваша программа или сайт будут автоматически опубликованы (доставлены) с вашими изменениями, избавляя вас от необходимости делать это вручную.
4. CD Интеграция с другими сервисами: Вы можете настроить пайплайн таким образом, чтобы его шаги взаимодействовали с различными инструментами и платформами, такими как Telegram или облачные сервисы. Например об неуспешном шаге отправлялось сообщение в рабочий канал в Telegram.

Вопросы по Git

1. Зачем нужен Git и GitHub?
2. Как создать commit?
3. Что уникального в каждом commit?
4. В чем разница между branch и tag?
5. Как создать branch?
6. Как переключаться между branch?
7. Как создать tag?
8. Что такое merge request?
9. В чем разница между merge и rebase?
10. Как решать конфликты при merge request?
11. Как клонировать репозиторий из интернета к себе на компьютер?
12. Как отправить свои внесенные изменения в удаленный репозиторий интернет?
13. В чем разница между fetch и pull?
14. Как сделать так, чтобы Git не следил за отдельными файлами?
15. Как откатить (отменить последние 4 коммита) изменения?

Вопросы по GitHub и CI/CD

1. Что такое CI/CD-пайплайн?
2. Какие шаги входят в пайплайн?
3. Как выглядит CI/CD-пайплайн в GitLab?
4. Где в репозитории хранится описание пайплайна?
5. Что может стать причиной запуска CI/CD-пайплайна?
6. Каким должен быть «идеальный» CI/CD-пайплайн?
7. Где выполняются шаги из CI/CD-пайплайна и почему именно там?
8. Могут ли шаги в пайплайне выполняться одновременно (параллельно)?
9. Что такое артефакты и где они хранятся?
10. Как ускорить CI/CD пайплайн?

Первое задание

1. Установи себе git в системе.
2. Создай репозиторий.
3. В директории репозитория создай файл text.txt и запиши в него слово DevOps.
4. Посмотри статус git.
5. Сделай коммит.
6. Проверь статус.

Второе задание

1. Создайте новый репозиторий на GitHub.
2. Загрузите его на свой компьютер.
3. Если файл README.md не существует, создайте его с содержимым: ### Мой первый проект.
4. Внесите изменения в файл и зафиксируйте их (сделайте коммит).
5. Отправьте свои изменения обратно на GitHub с помощью Git.
6. Убедитесь, что изменения были успешно внесены в ваш репозиторий на GitHub.
7. В своем репозитории на GitHub создайте новую ветку под названием test.
8. Разместите свой проект на GitHub Pages (он станет таким же сайтом, как и тот, на котором вы сейчас учитесь).
9. Каким образом работают GitHub Pages?
10. Можно ли настроить CI/CD через GitHub Actions?
11. Приведите пример CI/CD, используя GitHub Pages.