Сборочное окружение и зависимости при разработке

Представление. FrBrGeorge и ALT Linux Team (в частности FrBrGeorge и ALT Linux Team ☺)

О чём не будет рассказано в лекциях, но что необходимо тем не менее знать / уметь:

• Как администрировать свою Linux-систему

  • Как ставить/удалять/обновлять пакеты

  • Как эти пакеты называются в разных дистрибутивах

  • Как настраивать какие-то службы

  • …

• Как работать с редактором vim

  • Как работать в консольном текстовом редакторе

• Что такое командная строка и как в ней работать

  • Где найти и как запустить эмулятор терминала ☺

  • Терминал как управляющее устройство (Ctrl+C, Ctrl+S и т. п.)

  • Опыт работы с (произвольной) командной строкой

  • Знакомство с bash / zsh

  • Управление процессами в Linux (kill)

• Как программировать на Си

  • предполагается, что как-то вы это умеете ☺

• Как работать с Git

  • Базовые команды git

  • Как сопровождать простой публичный репозиторий

• Как работать с secure shell

  • Если вам необходим аккаунт на сервере Д/З, ssh придётся освоить

Стадии разработки приложения

Приложение:

• Разработка

  • Исходный код, документация, мультимедиа

  • Сборка программного продукта

  • Тестирование и отладка

• Деплоймент

  • Локальный тестовый деплоймент

  • Репозиторий и доставка
  • Установка и развёртывание
  • Сопровождение

Значком отмечены области, которые мы так или иначе затронем

Цикл разработки

(«Для самых маленьких»):

1. Редактирование
2. Сборка и подготовка к запуску
3. Тестирование и запуск

Редактирование

Текстовый редактор для программирования — это:

• синтаксис

• рецепты сборки

• многофайловые проекты и связи между файлами

• инфоподдержка

• отладчик
• рецепты деплоймента
• чёрт в ступе…

Мы ограничимся только , для остального будем использовать внешние инструменты

⇒ Сборочное окружение:

• Компилятор и компоновщик

• Дополнительные библиотеки или модули (для запуска)

• Сборочные варианты библиотек и include-файлы (т. н. devel-версии)
• Текстовый редактор
• VCS
• Обработка непрограммных компонентов (i18n, мультимедиа и т. п.)
• Оркестрация сборки сложного проектa (make, ninja, cmake, meson и т. п.)
• Парсер библиотек и бинарников и прочие информационные утилиты
• Отладчик, трассировщик выполнения, профайлер и иные средства диагностики

• (возможно) инструменты пакетирования и деплоймента

• …

В классическом Linux-дистрибутиве эти инструменты не обязаны присутствовать «из коробки» — их надо устанавливать из т. н. пакетов.

• Пакеты — это материал целого курса, увы.

Зависимости

Что мы поставили в сборочное окружение?

• Инструментальные зависимости: ПО, необходимое для поддержки процесса разработки.

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

  • система контроля версий (например, git)

  • отладчик и профилировщик
  • руководства и прочая документация
  • Подсистема тестирования
  • …

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

  • Компилятор и компоновщик
  • Средства автоматизации сборки (например, GNU Make)
  • Devel-версии библиотек (в частности, include-ники)
  • Другие средства преобразования исходников (подготовка документации и т. п.)
  • …

• Эксплуатационные зависимости: всё, что необходимо для запуска и использования установленного приложения

  • Используемые разделяемые библиотеки или модули высокоуровневых ЯП
  • Запускаемые приложением другие приложения и сервисы, к которым приложение обращается

Строго говоря, мы можем программировать в окружении, содержащем только инструментальные зависимости, собирать дистрибутив в окружении, содержащем только сборочные зависимости, а для запуска доустанавливать только эксплуатационные. Пример — сборка \Git6Hub-ом под несколько платформ.

Мы же используем очень олдскульный вариант «где собрал, там и зспустил», поэтому установили все три набора.

(если нужно) GIT

Базовый сайт: Pro GIT

VCS:

• Хранение
• Версионирвание
• Совместная разработка

DVCS:

• ∄ единого места хранения (с точки зрения протокола взаимодействия, так-то вполне может существовать т. н. «precious source» репозиторий / ветка)

Общие понятия (не все):

• Репозиторий
  • Локальная копия
  • Репозиторий для публикации
• Рабочая копия
• Коммит как срез состояния репозитория на опередённый момент
  • Обязательное описание коммита (commit message)

Цикл работы

0. клонирование (git clone)

1. (повторно и далее) Синхронизация (git pull = git fetch + git merge)

2. Изменение

3. Отметка файлов для коммита (git add)

4. Коммит (git commit)

5. Переход к 2. или 3.

6. Публикация (git push)

Свойства GIT:

• Хранение всех версий исходников

• Хранение полного репозитория в локальной копии

• Отслеживание процесса разработки в виде орграфа (нам пока нужен только линейный)

  • ⇒ понятие «ветка», «слияние веток» и т. п.

Доступ к сборочной среде

Варианты сборочного окружения:

• Собственный компьютер с каким-то Linux (см начало лекции)

• Собственный компьютер с дистрибутивом ALT (инструкция)

  • Для любителей посвежее — можно попробовать стратовые наборы для проектируемых дистрибутивов или даже роллинг (на сервере Д/З установлен именно роллинг)

• Виртуалка с тем или другим (например, Virtualbox или WSL2)

• Аккаунт на Д/З-сервере
  • Пишите в tg-личку заявку о выделении аккаунта

  • Понадобится владение ssh

  • Понадобится владение консольным текстовым редактором (есть, конечно же, vim, а также nano, mc и micro

  • Всё остальное уже настроено!

Изолированная сборка и пакетирование

Недостатки подхода «где собрал, там и запустил»

1. Нужно ставить сборочные зависимости прямо в хост-систему:

   • они могут конфликтовать,
   • они могут мешать общей работе,
   • хост-система как сборочное окружение постоянно меняется, и проекты то собираются, то нет — неясно отчего.
2. Запуск из каталога, в котором программу собрали, не подходит для production:

   • легко случайно поменять что-нибудь (actually, всегда),

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

   • неочевидно, как другой пользователь будет запускать программу.

Проблема (1) решается введением выделенного сборочного окружения:

• Отдельная виртуальная машина
• Типовое изолированное окружение (а-ля docker)

• Специализированное сборочное изолированное окружение (например ALT hasher):

  • нулевая потеря производительности,
  • сравнительно небольшой footprint,
  • воспроизводимая сборка, в т. ч. для репозиториев и даже платформ ≠ хост-системе,

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

Два последних свойства требуют переразвёртывания окружения ⇒ tmpfs.

Проблема (2) решается пакетированием:

• Пакет — это архив с установочными файлами + некоторые дополнительные свойства (например, зависимости пакетов)
• Размещение установочных файлов проекта (в системе или в выделенном каталоге) сообразно дисциплине
• Унифицированные установочные и деустановочные сценарии
• Работа с пакетами требует прав суперпользователя

Использование hasher (и интеграция с git при помощи ALT Gear), а также создание пакета рассмотрено в проекте лабораторных для Альт Платформы по данному курсу.

Д/З

1. Обеспечить (себе) доступ к Linux-системе,
   • в которую можно устанавливать произвольное ПО из репозитория
   • вариант:

2. Завести публичный git-репозиторий и зарегистрировать его в качестве комментария к этому issue

   • GIT заводится где угодно, лишь бы было опубликовано и мне можно было сделать git clone (GitHub, GitLab, факультетский GitLab для студентов, любой иной способ):

   • Скорее всего вам понадобится сгенерировать и зарегистрировать ssh-ключ

Отпечаток ключа linuxprac:

ED25519 key fingerprint is MD5:55:1e:6a:4c:32:99:1b:fb:fa:d3:15:b9:a5:6b:94:53.
+--[ED25519 256]--+
|        oo. o    |
|        += + .   |
|         += .  . |
|        oo    o E|
|        S.     B |
|          .   B  |
|         . . o o |
|        . . . o  |
|         ... .   |
+------[MD5]------+