CICD

Практика по CI/CD

Тема 1

Тема:

Работа с системой контроля версий git. 

Отчёт:

В отчёт необходимо включить результат последовательного выполнения шагов 1.* и вывод по достигнутым результатам.

Каждой теме и каждому шагу в отчёте необходимо дать осмысленное название.

В имени пользователя и электронной почте в конфигурационном файле git-проекта должны фигурировать реальные фамилия и инициалы обучающегося.

Шаг 1.1

Создайте проект с исходным кодом программного обеспечения на компьютере разработки

mkdir ~/my_program

Перейдите в проект

cd ~/my_program

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

touch main.c

поместите в созданный файл следующее содержимое:

#include <stdio.h>

int main() {
    printf("Hello from program!\n");
    return 0;
}

Создайте файл Makefile:

touch Makefile

поместите в созданный файл следующее содержимое:

CC = gcc

TARGET = main
SRC = main.c

CFLAGS = -Wall -Wextra

all: $(TARGET)
$(TARGET): $(SRC)
	$(CC) $(CFLAGS) $(SRC) -o $(TARGET)

run: $(TARGET)
	chmod +x $(TARGET)
	./$(TARGET)

clean:
	rm -f $(TARGET)

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

touch .gitignore

поместите в созданный файл следующее содержимое:

main

Шаг 1.2

Перейдите в проект

cd ~/my_program

Соберите программы

make

Сделайте файл получившейся программы исполняемым и запустите

make run

Просмотрите файлы проекта

ls -l

Опишите проделанную работу в отчёте.

На этом этапе была создана простейшая программа на языке си с простейшим файлом сборки, произведена сборка программы и её запуск.

Шаг 1.3

Перейдите в проект:

cd ~/my_program

Инициализируйте контроль версий кода проекта посредством git:

git init

Переименуйте главную ветку из master в main согласно современным договорённостям разработчиков:

git branch -m main

Посмотрите содержимое файла .git/config

cat .git/config

Добавьте к содержимому этого файла следующие параметры:

[user]
	name = <ваше имя>
	email = <ваш емэйл>

Например:

[user]
	name = petrov_ii
	email = petrov@mail.com

Замените утилиту постраничного просмотра git на cat (это предотвратит необходимость выхода из постраничного навигатора):

git config core.pager cat

Посмотрите повторно содержимое файла .git/config

cat .git/config

Найдите взаимосвязь между выполненной выше командой и параметрами внутри конфигурационного файла.

Подсказка: Для установки параметров name и email в разделе user вместо ручного редактирования файла можно было бы выполнить команды:

git config core.name=petrov_ii
git config core.email=petrov@mail.com

Кстати, если понадобится их поменять, то можно попробовать этот вариант тоже.

Шаг 1.4

Добавьте содержимое каталога к будущему коммиту

git add .

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

git commit -m "My first commit"

Просмотрите журнал коммитов:

git log

Внесите изменения в файл main.c (например, измените выводимое текстовое сообщение). Затем просмотрите изменённые файлы в проекте:

git status

Просмотрите также разницу между состоянием файлов проекта в последнем коммите и текущим состоянием:

git diff

Верните состояние файла main.c к состоянию, в котором он был на предыдущем коммите:

git checkout -f main.c

Проверьте содержимое файла

cat main.c

Повторно просмоте статус проекта:

git status

Внесите ещё раз изменения в файл main.c (например, измените выводимое текстовое сообщение). Затем просмотрите изменённые файлы в проекте:

git status

Просмотрите повторно разницу между состоянием файлов проекта в последнем коммите и текущим состоянием:

git diff

На этот раз сохраните изменения в файле путём создания нового коммита. Для этого добавьте изменённый файл к отслеживанию системой контроля версий:

git add main.c

(здесь важно понимать, что, не смотря на то, что когда-то вы уже делали это (git add .), после изменения содержимого файла для добавления изменений в коммит его (файл) нужно повторно добавить к отслеживанию. Т.е. мы добавляем не сам файл, а факт изменения этого файла)

Теперь повторно выполните команду:

git status

В результате будет виден текущий статус изменений, подготовленных для коммита.

После сделайте новый коммит:

git commit -m "My second commit"

Просмотрите журнал коммитов:

git log

Также не лишним будет повторно посмотреть и статус

Шаг 1.5

Перейдите в проект

cd ~/my_program

Просмотрите доступные ветки проекта

git branch

Скорее всего в ответ придёт что-то вроде:

* main

Это означает что у вас в проекте одна ветка (branch) и она называется

main

Просмотрите журнал коммитов:

git log

В ответ придёт что-то вроде:

commit 477a3a1f243a7e62806c8239b3f193f839007c02 (HEAD -> main)
Author: petrov_ii <petrov@mail.com>
Date:   Mon Jan 19 11:36:04 2026 +0300

    Second

commit d0b5b111f559379b90f98cf417a372bd55d02774
Author: petrov_ii <petrov@mail.com>
Date:   Mon Jan 19 11:31:20 2026 +0300

    First

Ранее мы могли вернуть изменённый файл main.c к состоянию последнего коммита командой

git checkout -f main.c

Эта команда возвращает содержимое файла main.c на состояние, сохранённое коммитом. При этом то состояние, которое у файла было до выполнения этой команды, будет полностью потеряно.

Имея историю коммитов, при необходимости, можно вернуть состояние всего проекта к состоянию любого из коммитов.

Для этого необходимо выполнить команду:

git checkout <id коммита>

Например

git checkout d0b5b111f559379b90f98cf417a372bd55d02774

Важно понимать, что такое переключение на конкретный коммит стоит использовать с осторожностью и исключительно как временную меру.

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

После переключения на конкретный коммит и выполнения действий с файлами проекта необходимо обратно вернуться на базовое состояние текущей ветки:

git checkout <имя ветки>

Например, в случае с веткой main:

git checkout main

Шаг 1.6

На шаге 1.1 был создан файл:

.gitignore

в котором описаны файлы и каталоги, которые система контроля версий git должна игнорировать.

По этой причине создаваемый при сборке исполняемый файл:

main

Не отображается при выполнении команды:

git status

и не был добавлен при выполнении команды:

git add .

(точка здесь означает все файлы, которые могут быть добавлены к контролю версий. Однако, файла main не было добавлен!).

В git-проекте принято хранить исходный код без продуктов сборки (чем является исполняемый файл main). По этой причине он был добавлен в файл:

.gitignore

, чтобы git игнорировал его.

Шаг 1.7

Измените несколько раз содержимое файла:

main.c

Добавьте каждое изменение для отслеживания системой контроля версии, а также выполните коммит для каждого изменения.

Выполняя коммит необходимо наиболее полно составлять текстовый комментарий, который должен отражать реальное состояние внесённых изменений.

В отчёте необходимо отразить работу с внесением изменений в проект, по результатом которой в журнале должно быть отображено не менее 10-ти коммитов.

Шаг 1.8

Ответьте на вопросы.

Разместите вопросы и ответы на них в отчёте.

Список вопросов:

1. Какая команда позволяет инициализировать процесс контроля версий в каталоге проекта посредством системы контроля версий git?
2. Какой командой добавить файл test.txt к отслеживанию системой контроля версий git?
3. Какой командой можно сделать коммит, указав сообщение коммита?
3. Укажите путь до имени конфигурационного файла git-проекта относительно каталога git-проекта?
4. Какой командой можно переключить состояние проекта на конкретный коммит?
5. Какой командой можно переключить состояние проекта на самый новый по времени создания коммит?

Тема 2

Тема:

Работа с DevOps платформой gitlab.

Отчёт:

В отчёт необходимо включить результат последовательного выполнения шагов 2.* и вывод по достигнутым результатам.

Каждой теме и каждому шагу в отчёте необходимо дать осмысленное название.

Шаг 2.1

В теме 1 были рассмотрены основы работы с системой контроля версий git.

Навыки, полученные в теме 1, позволят на базовом уровне обеспечить контроль над содержимым проекта.

Однако при совместной работе над кодом только локального контроля версий недостаточно.

Обычно, для синхронизации локального каталога с проектом между различными разработчиками (или между различными рабочими местами одного разработчика) в дополнение к системе контроля версий git используются платформы для хранения и обеспечения условий для совместной работы над кодом, такие как: GitHub, GitLab, GitFlic и другие...

К общим функциям таких порталов можно отнести:

1. Хранение кода и механизмы предоставления доступа к коду между различными разработчиками;
2. Подсистема для хранения и обсуждения ошибок и неисправностей в коде (issues), тесно интегрированная с существующим механизмом коммитов системы контроля версий git;
3. Подсистемы обеспечения непрерывной интеграции (CI - Continuous Integration);
4. Подсистемы обеспечения непрерывной доставки (CI - Continuous Delivery);
5. Подсистемы сбора артефактов;
6. Подсистемы публикации релизов программного обеспечения.

Возможности современных CI/CD платформ, таких как GitHub или GitLab позволяют автоматизировать многие рутинные операции, такие как: тестирование кода, сборка, развёртывание (deployment), выпуск новых версий ПО.

Платформа GitLab позволяет использовать свою версию с открытым исходным кодом для самостоятельного развёртывания энтузиастами или небольшими организациями в пределах локальной сети предприятия или в пределах облачного хостинга организации. С этой точки зрения для использования в образовательных целях эта платформа также представляет большой интерес.

Дальнейшие основы CI/CD в рамках этого практического пособия будут даны на примере CI/CD платформы GitLab, расположенной по адресу https://gitlab.nntc.nnov.ru

Шаг 2.2

Войдите в свой аккаунт на https://gitlab.nntc.nnov.ru и создайте новый git-репозиторий.

Имя репозитория должно содержать фамилию и инициалы обучающегося.

Например, для обучающегося с ФИО Петров Иван Иванович, проходящего учебную практику, название репозитория может быть таким:

Тема 3

Тема:

Организация доступа на GNU/Linux хост посредством протокола ssh. Установка gitlab-runner на GNU/Linux хост.

Отчёт:

В отчёт необходимо включить результат последовательного выполнения шагов 3.* и вывод по достигнутым результатам.

Каждой теме и каждому шагу в отчёте необходимо дать осмысленное название.

Шаг 3.1

Посредством утилиты:

ssh-keygen

создайте ключевую пару (открытую и закрытую части криптографического ключа).

Обычно результатом создания ключевой пары являются файлы:

id_ed25519
id_ed25519.pub

или:

id_rsa
id_rsa.pub

(в зависимости от типа шифрования, настроенного операционной системе, на которой создаётся ключевая пара).

Файл с суффиксом:

.pub

содержит открытую часть ключа. Второй файл, соответственно, содержит закрытую часть ключа.

Закрытую часть сохраните у себя и ни кому не передавайте (это ваш будущий ключ от удалённого GNU/Linux хоста).

Содержимое открытой части ключа добавьте к содержимому файла:

authorized_keys

, который обычно находится в каталоге:

.ssh

внутри домашнего каталога пользователя, под которым вы планируете подключаться на GNU/Linux хост по протоколу ssh.

Да, верно: открытую часть ключа следует доставить на удалённый GNU/Linux хост и положить в выше упомянутый файл в выше упомянутом каталоге того пользователя удалённого GNU/Linux хоста, под которым планируется подключение.

Шаг 3.2

Для процедуры доставки открытой части ключа можно воспользоваться утилитой:

ssh-copy-id

(если это позволяют настройки безопасности удалённого GNU/Linux хоста) либо в ручном режиме переместить содержимое открытого ключа в необходимый файл на удалённом хосте, предварительно подключившись на удалённый GNU/Linux хост по протоколу ssh по логину и паролю.

При корректной настройке удалённого GNU/Linux хоста к нему можно будет подключаться, используя закрытую часть ключа, командой, общий вид которой следующий:

ssh -i </путь/до/закрытой_части_ключа> <пользователь>@<хост_или_ip_адрес> -p <порт>

Если порт ssh сервера, к которому производится подключение, стандартный (22), то ключ -p с номером порта в команде можно опустить.

Пример команды:

ssh -i ~/.ssh/id_ed25519 user@10.207.123.123 -p 22

При выполнении такой команды подразумевается, что содержимое файла:

id_ed25519.pub

находится в файле:

/home/user/.ssh/authorized_keys

на GNU/Linux хосте с ip-адресом:

10.207.123.123

а ssh сервер работает на этом же хосте на стандартном порту

22

(как уже говорилось выше, ключ -p 22 в команде можно опустить, если порт сервера стандартный -- 22-й).

Шаг 3.3

Предыдущие два шага демонстрируют процесс настройки БЕЗОПАСНОГО доступа на уалённый сервер.

Безопасным доступом в этом контексте является доступ с аутентификацией по ключам, а не по паролю (пароль может быть подобран извне специализированным программным обеспечением).

Следовательно, категорически не рекомендуется оставлять доступ по паролю на удалённый сервер!

Когда доступ на удалённый сервер (GNU/Linux хост) получен, на нём необходимо установить и настроить средство выполнения для gitlab.

Это программное обеспечение называется:

gitlab-runner

В некоторых GNU/Linux дистрибутивов gitlab-runner может входить в состав репозитория программного обеспечения.

Далее будет рассмотрена процедура установки средства выполнения "gitlab-runner" универсальным способом.

Шаг 3.4

1. Подключитесь к серверу по протоколу ssh;

2. Перейдите в режим суперпользователя;

3. Загрузите бинарную версию средства выполнения "gitlab-runner" для сервера архитектуры x86_64 (она же amd64) командой:

curl -L --output /usr/local/bin/gitlab-runner https://wiki.nntc.nnov.ru/download/gitlab-runner-linux-amd64

4. Сделайте загруженный файл исполняемым:

chmod +x /usr/local/bin/gitlab-runner

5. Добавьте пользователя, от имени которого будет работать средство выполнения

useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

6. Установите и запустите средство выполнения как сервис

gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
gitlab-runner start

Готовые бинарные сборки средства выполнения "gitlab-runner" существуют также под архитектуры 386, arm и arm64.

Для снижения нагрузки на интернет-канал лабораторий колледжа в команде (п.3) установки используется локальная ссылка.

Более подробную информацию по установке средства выполнения можно получить здесь

На этом этапе на GNU/Linux хост установлено средство выполнения "gitlab-runner", посредством которого можно будет выполнять непрерывную интеграцию (CI) и непрерывную поставку/доставку контента (CD).

Для этого необходимо связать gitlab-репозиторий со средством выполнения. Об этом подробно расскзано в теме 1.

Шаг 3.5

Сделайте полный вывод о проделанной работе по теме 0.

Шаг 3.6

Ответьте на вопросы и разместите вопросы и ответы на них в отчёте.

Список вопросов:

1. Для чего нужна утилита ssh-keygen?
2. Для чего нужна утилита ssh-copy-id?
3. Для чего нужен файл ~/.ssh/authorized_keys?
4. Сколько файлов создаётся при создании ключа ssh?
5. Для чего служит средство выполнения "gitlab-runner" на сервере, на котором оно установлено и запущено?

Тема 4

Тема:

Создание проекта в https://gitlab.nntc.nnov.ru, настройка gitlab-runner, создание простейшего файла .gitlab-ci.yml

Отчёт:

В отчёт необходимо включить результат последовательного выполнения шагов 4.* и вывод по достигнутым результатам.
Название gitlab-проекта обязательно должно включать фамилию обучающегося.

Отчёт должен содержать ссылку на существующий git-репозиторий, описанный в отчёте.

Каждой теме и каждому шагу в отчёте необходимо дать осмысленное название.

Шаг 4.1

Войдите в свой аккаунт на https://gitlab.nntc.nnov.ru и создайте новый git-репозиторий.

Имя репозитория должно содержать фамилию и инициалы обучающегося.

Например, для обучающегося с ФИО Петров Иван Иванович, проходящего учебную практику, название репозитория может быть таким:

up_petrov_ii

Шаг 4.2

Перейдите на страницу созданного репозитория.

Найдите раздел "Средства выполнения" в меню "Настройки - CI/CD"

Создайте средство выполнения, заполнив форму следующим образом:

Теги:

test

Остальные параметры оставьте по умолчанию, затем нажмите кнопку:

Создать средство выполнения

На следующей странице ознакомьтесь с пошаговой инструкцией по запуску средства выполнения gitlab-runner (пройдите по предлагаемым ссылкам инструкции чтобы ознакомиться наиболее полно!), скопируйте команды, которые в последующем понадобятся для запуска средства выполнения на GNU/Linux хосте, затем нажмите на кнопку:

Просмотр средств выполнения

В результате в списке средств выполнения появится ваше средство выполнения, которое будет иметь номер и уникальное название. Например:

#20 (LDBWhOpr)

Шаг 4.3

Рядом с созданным на предыдущем шаге средством выполнения будет показан треугольный значок с восклицательным знаком. Это означает, что gitlab не подключился к средству выполнения на GNU/Linux хосте. Теперь необходимо это настроить.

Используйте скопированные ранее команды чтобы зарегистрировать средство выполнения на GNU/Linux хосте. Для этого:

1. Войдите на GNU/Linux хост по протоколу ssh;

2. Выполните команду для регистрации средства выполнения;

3. Перейдите на страницу "Средства выполнения" проекта;

4. Убедитесь что треугольный значок с восклицательным знаком пропал и на его месте появился зелёный кружок, символизирующий успешное подключение gitlab к средству выполнения (к gitlab-runner-у).

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

Шаг 4.4

Склонируйте ваш репозиторий себе на компьютер и создайте внутри файл

.gitlab-ci.yml

со следующим содержимым

stages:
  - test

hello_job:
  stage: test
  tags:
    - test
  script:
    - echo "Hello from GitLab CI"
    - uname -a
    - echo "Hello from GitLab CI" > /tmp/test
    - uname -a >> /tmp/test

Сделайте коммит (git commit) и синхронизируйте изменения с репозиторием (git push).

Затем перейдите в средство выполнения ("Сборка" - "Средства выполнения") в меню вашего репозитория в gitlab и посмотрите статус задания.

Опишите результат в отчёт.

Затем войдите по протоколу ssh на GNU/Linux хост, на котором работает средство выполнения и просмотрите содержимое файла:

/tmp/test

Опишите результат исследования файла на GNU/Linux хосте.

Шаг 4.5

Сделайте вывод о проделанной работе по теме 1.

Опишите связь между работой средства выполнения и содержимым файла:

.gitlab-ci.yml

Шаг 4.6

Ответьте на вопросы.

Разместите вопросы и ответы на них в отчёте.

Список вопросов:

1. Сколько команд будет выполнено средством выполнения?
2. Какие именно это команды?
3. Какие команды формируют содержимое файла test в каталоге /tmp GNU/Linux хоста?
4. Как связано название стадии (stage) и названия тегов, указываемых при конфигурировании средства выполнения?
5. На что влияют названия тегов, указываемых при конфигурирования средства выполнения?

Тема 5

Тема:

Создание артефактов посредством gitlab-runner

Отчёт:

В отчёт необходимо включить результат последовательного выполнения шагов 5.* и вывод по достигнутым результатам.

Каждой теме и каждому шагу в отчёте необходимо дать осмысленное название.

Тема 6

Тема:

Создание артефактов посредством gitlab-runner

Отчёт:

В отчёт необходимо включить результат последовательного выполнения шагов 5.* и вывод по достигнутым результатам.

Каждой теме и каждому шагу в отчёте необходимо дать осмысленное название.

Тема 7

Тема:

Контрольное задание

Отчёт:

В отчёт необходимо включить результат выполнения индивидуального контрольного задания, в котором необходимо выполнить следующее:

1. Не менее пяти стадий (stages) в файле .gitlab-ci.yaml;
2. Не менее двух стадий должны обмениваться артефактами (один или более артефакт);
3. Финальная стадия должна публиковать релиз программного обеспечения.