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

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

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.

Вопросы и задания по теме “Управление версиями проектов и автоматизация”

Теоретические вопросы (20 вопросов)

1. Что такое Git и зачем он нужен?

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

2. В чем разница между репозиторием и обычной папкой?

Ответ: Репозиторий — это папка проекта, внутри которой есть скрытая директория .git с полной историей изменений, настройками и метаданными. Обычная папка этого не содержит. Пояснение: Обычная папка — просто набор файлов. Репозиторий — как архив с журналом, где хранится история всех правок и их авторов.

3. Что происходит при создании коммита?

Ответ: Git сохраняет “снимок” текущих изменений, которые были добавлены в staging area (git add). Коммит хранит:

• изменения файлов;
• имя автора;
• дату и время;
• комментарий (описание);
• уникальный ID (хеш). Пояснение: Это как зафиксировать состояние проекта на фото и подписать, что изменилось.

4. Разница между git add и git commit?

Ответ: git add — добавляет изменения в список на фиксацию (staging). git commit — сохраняет эти изменения в истории проекта. Пояснение: add — как положить вещи в корзину в магазине. commit — как оплатить их на кассе и зафиксировать покупку.

5. Зачем нужны ветки (branches)?

Ответ: Чтобы вести параллельную разработку функций или исправлений, не затрагивая стабильную версию кода. Пояснение: Представь шоссе с основным движением (main) и отдельными съездами (ветки) для новых функций. Когда дорога готова, съезд подключают обратно.

6. Разница между веткой и тегом?

Ответ: Ветка — подвижная ссылка на текущий коммит, в которую можно добавлять новые коммиты. Тег — метка на конкретной версии, которая не меняется. Пояснение: Ветка — как закладка в книге, которую можно двигать. Тег — как надпись на странице “Глава 5”, которую уже не переставишь.

7. Что такое merge conflict и почему он возникает?

Ответ: Это ситуация, когда Git не может автоматически объединить изменения, потому что одна и та же строка файла была изменена в разных ветках. Пояснение: Как если два человека одновременно правят одну и ту же фразу в документе, но по-разному. Нужно вручную выбрать, какая версия останется.

8. Разница между merge и rebase?

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

9. Что такое fast-forward merge?

Ответ: Это слияние, при котором ветка назначения просто перемещает указатель вперёд на новые коммиты другой ветки без создания merge-коммита. Пояснение: Как перелистать книгу на несколько страниц вперёд, если между страницами не было других изменений.

10. Как откатить последние изменения в Git?

Ответ:

• git reset — удаляет коммиты (локально).
• git revert — создаёт новый коммит, отменяющий изменения (без удаления истории). Пояснение: reset — как стереть страницу из дневника. revert — как дописать на следующей странице “Отмена предыдущей записи”.

11. Чем Git отличается от GitHub?

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

12. Разница между git fetch и git pull?

Ответ: fetch загружает изменения с удалённого репозитория, но не применяет их к локальной ветке. pull делает fetch и сразу объединяет изменения с вашей веткой. Пояснение: fetch — “принести письма”, pull — “принести и сразу прочитать”.

13. Что такое Pull Request и зачем он нужен?

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

14. Для чего используется .gitignore?

Ответ: Чтобы указать Git, какие файлы и папки не нужно отслеживать. Пояснение: Например, временные файлы, логи, кэш, пароли. Это как список “не класть в чемодан”.

15. Разница между git clone и fork?

Ответ: clone — копия репозитория на ваш компьютер. fork — копия репозитория в вашем аккаунте на GitHub. Пояснение: clone — скачать файл к себе. fork — сделать копию в облаке под своим именем.

16. Что такое CI и CD?

Ответ:

• CI (Continuous Integration) — автоматическая проверка и сборка кода при каждом изменении.
• CD (Continuous Delivery/Deployment) — автоматическая доставка кода на сервер. Пояснение: CI — как проверка деталей на заводе, CD — как отправка готового изделия клиенту.

17. Что такое pipeline?

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

18. Какие события могут запустить pipeline?

Ответ: Коммит, Pull Request, слияние веток, выпуск тега, запуск по расписанию. Пояснение: Это “триггеры”, которые говорят системе: “Начинай работу”.

19. Что такое артефакты в CI/CD?

Ответ: Это результат сборки — исполняемые файлы, архивы, пакеты, отчеты о тестах. Пояснение: Это “готовый продукт” на выходе конвейера.

20. Пример идеального pipeline

Ответ: Линтинг → тесты → сборка → проверка безопасности → деплой → уведомление команды. Пояснение: Такой процесс минимизирует ошибки и ускоряет выпуск продукта.

Практические задания (5 заданий)

Задание 1: Создание репозитория и первые коммиты

Цель: Понять, что такое репозиторий, staging area, commit.

Шаги:

1. Создайте папку проекта:

   mkdir my-first-project && cd my-first-project
   

2. Инициализируйте Git:

   git init
   

3. Создайте файл с участниками команды:

   echo "Alice\nBob\nCharlie" > team.txt
   

4. Добавьте файл в staging area:

   git add team.txt
   

5. Сделайте первый коммит:

   git commit -m "Add team members"
   

6. Создайте файл с описанием проекта:

   echo "# My First Project" > project-info.md
   

7. Добавьте и закоммитьте:

   git add project-info.md
   git commit -m "Add project description"
   

8. Посмотрите историю:

   git log --oneline
   

Что вы поймёте: как фиксировать изменения и хранить историю проекта.

Задание 2: Работа с ветками

Цель: Освоить создание веток, переключение и слияние.

Шаги:

1. Создайте ветку:

   git branch feature/add-readme
   

2. Переключитесь в неё:

   git checkout feature/add-readme
   

3. Создайте README:

   echo "# My First Project\nThis is a sample project." > README.md
   

4. Сделайте коммит:

   git add README.md
   git commit -m "Add README"
   

5. Вернитесь в main:

   git checkout main
   

6. Убедитесь, что файла README.md нет:

   ls
   

7. Слейте ветку:

   git merge feature/add-readme
   

8. Удалите ветку:

   git branch -d feature/add-readme
   

Что вы поймёте: изоляция разработки и объединение изменений.

Задание 3: Подключение GitHub

Цель: Научиться работать с удалённым репозиторием.

Шаги:

1. На GitHub создайте репозиторий devops-practice (без README).

2. Подключите локальный репозиторий к GitHub:

   git remote add origin https://github.com/<ваш_логин>/devops-practice.git
   

3. Отправьте изменения:

   git branch -M main
   git push -u origin main
   

4. Создайте новую ветку на GitHub update-docs через веб-интерфейс.

5. Получите её локально:

   git fetch origin
   

6. Переключитесь:

   git checkout update-docs
   

7. Обновите документацию:

   echo "New feature: authentication" >> project-info.md
   git add project-info.md
   git commit -m "Add authentication feature to docs"
   git push origin update-docs
   

8. На GitHub создайте Pull Request.

Что вы поймёте: работа с GitHub и удалёнными ветками.

Задание 4: Решение merge conflict

Цель: Научиться устранять конфликты.

Шаги:

1. Создайте файл:

   echo -e "app_name=MyApp\nversion=1.0\nauthor=User" > config.txt
   git add config.txt
   git commit -m "Add config file"
   

2. Создайте ветку:

   git checkout -b feature/update-version
   

3. Обновите версию в этой ветке:

   sed -i 's/version=1.0/version=2.0/' config.txt
   git commit -am "Update version to 2.0"
   

4. Вернитесь в main:

   git checkout main
   

5. Измените версию:

   sed -i 's/version=1.0/version=1.5/' config.txt
   git commit -am "Update version to 1.5"
   

6. Попробуйте слить:

   git merge feature/update-version
   

7. Разрешите конфликт, оставив version=2.0.

8. Добавьте и закоммитьте:

   git add config.txt
   git commit
   

Что вы поймёте: как Git фиксирует конфликт и как его вручную разрешить.

Задание 5: Простой CI/CD с GitHub Actions

Цель: Увидеть автоматизацию на примере GitHub Actions.

Шаги:

1. Создайте папку:

   mkdir -p .github/workflows
   

2. Создайте файл .github/workflows/simple-ci.yml:

   name: Simple CI
   
   on:
     push:
       branches: [ main ]
     pull_request:
       branches: [ main ]
   
   jobs:
     test:
       runs-on: ubuntu-latest
       steps:
       - uses: actions/checkout@v2
       - name: Check files
         run: |
           echo "Checking project files..."
           ls -la
           echo "Project validation complete!"
   

3. Закоммитьте и отправьте:

   git add .github/workflows/simple-ci.yml
   git commit -m "Add simple CI workflow"
   git push
   

4. Создайте новый файл:

   echo "test" > test.txt
   git add test.txt
   git commit -m "Add test file"
   git push
   

5. Зайдите в GitHub → вкладка Actions и проверьте выполнение.

Что вы поймёте: как автоматизировать проверки при каждом изменении кода.