Подключаем Git к web-приложению на Python и Starlette

Web-приложение на Python и Starlette, разработку которого мы исследуем в этом цикле статей, разрабатывается последовательно от этапа к этапу. При этом, на каждом новом этапе разработки код приложения будет обновляться, получать дополнения и новые возможности. Git — это система контроля версий, которая позволит удобно и качественно отслеживать все обновления кода, даст возможность работать над проектом совместно с другими разработчиками и синхронизировать все копии кода. В очередном выпуске цикла поговорим о подключении Git в проект.

Зачем нужен Git

Git — это вспомогательный инструмент. В сущности, web-приложение может существовать и без него, но Git качественно помогает синхронизировать копии. Копии приложения существуют на рабочих компьютерах каждого участника проекта, если над проектом работает несколько разработчиков. Кроме этого, отдельная копия впоследствии будет установлена на сервер сети. Главная задача Git — это последовательная, многократная синхронизация всех этих копий.

Допустим, у нас есть развёрнутое на сервере приложение, и его необходимо качественно доработать в некоторых аспектах, при этом мы не можем остановить сервер на время отладки и тестирования всех сделанных изменений. Мы разрабатываем приложение на рабочем десктопе, тестируем, отлаживаем, опять тестируем. В результате этих действий на рабочем десктопе появляется новая версия приложения, которую затем необходимо установить на сервер. И без Git эта рутина станет настоящим проклятием web-мастера. С системой контроля версий у нас появляется возможность синхронизировать все имеющиеся копии приложения с хранящейся на Git-сервере копией парой простых консольных команд.

Установка Git

Установка и предварительная настройка Git с настройкой подключения к серверу github.com по протоколу SSH детально описаны в соседнем блоге по предложенной ссылке. Кроме этого, там же, в соседнем блоге рассматриваются другие вопросы, связанные с установкой, настройкой и прикладным использованием операционной системы Debian, рекомендую подписаться и следить за обновлениями.

Создание Git-хранилища в структуре web-приложения

Первое, на что следует обратить внимание перед созданием Git-хранилища на локальном компьютере, это структура каталогов web-приложения, вот как выглядит дерево каталогов на текущий момент.

На снимке экрана выше я выделил красным фломастером каталоги и файлы, которые не должны попасть в Git-хранилище. Давайте я перечислю их ещё раз.

1. Каталог с именем venv хранит виртуальное окружение, в котором web-приложение разрабатывается. Этот каталог не является авторским, его содержимое я получил из сторонних источников. И этому каталогу не место в публичном Git-хранилище.

2. Группа каталогов с именем __pycache__. Каталог с таким именем присутствует в базовом каталоге приложения и во всех вложенных каталогах с подпрограммами. В настоящий момент у приложения одна подпрограмма — main, и в её каталоге __pycache__ тоже имеется. В этих каталогах хранятся бинарные копии исполняемого интерпретатором кода, и их попадание в публичное Git-хранилище крайне нежелательно.

3. Каталоги generic и .webassets-cache созданы автоматически соответствующими инструментами модуля Webassets. Этим каталогам совсем не место в публичном Git-хранилище.

4. В каталоге vendor хранится код сторонних библиотек для разработки frontend приложения, этот каталог тоже попадает в исключения.

5. Файл настроек приложения с именем .env. Содержимое этого файла в рабочей копии приложения на десктопе разработчика будет отличаться от содержимого этого же файла в копии приложения на сервере сети. Это значит, что на сервере сети этот файл будет необходимо отредактировать. Поэтому этот файл тоже попадает в исключения для Git-хранилища.

Приступим к решению основной задачи этой демонстрации. Запускаю терминал, вхожу в корневой каталог web-приложения и активирую в этом терминале виртуальное окружение.

Исключения для Git создать очень просто, достаточно отредактировать в корневом каталоге приложения файл с именем .gitignore. Следующая команда создаст этот файл.

$ vim .gitignore

В этот файл я впишу все только что перечисленные имена. Поскольку я работаю над приложением в Vim, сюда же я помещу ещё два шаблона исключений: *.pyc и *.swp.

*.pyc
*.swp
.env
__pycache__
venv
vendor
.webassets-cache
generic

Сохраняю изменения в файл и покидаю текстовый редактор.

Поскольку файл с настройками приложения попал в исключения, в Git-хранилище должна быть его копия с другим именем, с помощью которой я впоследствии с лёгкостью восстановлю файл настроек на сервере сети и отредактирую его в соответствии с требованиями. Создаю такую копию.

$ cp .env env_template

В виртуальное окружение на предыдущих этапах проектирования я установил необходимые приложению сторонние библиотеки. Впоследствии, при развёртывании приложения на сервер сети мне будет необходимо восстановить виртуальное окружение на сервере и установить в него все используемые библиотеки. Чтобы сделать это без ошибок и с минимальными затратами труда и времени, создаю файл со списком зависимостей. Сделать это можно при помощи pip.

$ pip freeze > requirements.txt

Вот как выглядит мой терминал после проделанных действий.

Кроме сторонних библиотек установленных из PyPI, на сервере сети будет необходимо установить некоторые нужные для запуска приложения пакеты из официального хранилища Debian, именно эту операционную систему я планирую использовать на сервере. Чтобы впоследствии можно было установить их одной командой, создаю список необходимых пакетов. Хранить этот список я планирую в отдельном каталоге, вложенном в корневой каталог приложения. Создаю его.

$ mkdir deployment

В только что созданном каталоге с именем deployment создаю текстовый файл с именем packages.

$ vim deployment/packages

В этот файл помещаю имена пакетов из пакетной базы Debian.

python3-venv
python3-dev
build-essential

Далее в процессе разработки web-приложения этот список будет значительно расширен и дополнен. А пока сохраняю изменения в файл и вновь покидаю текстовый редактор.

Поскольку каталог с именем vendor попал в исключения для Git, при развёртывании приложения на сервер сети мне будет необходимо восстановить этот каталог и всё его содержимое. Чтобы сделать этот одной командой, упаковываю каталог vendor в архив, а архив размещаю в каталоге deployment. Вот команда для этого действия.

$ tar cvzf deployment/vendor.tar.gz -C webapp/static vendor

Вполне вероятны обстоятельства, при которых развёртывание приложения на сервер сети будет осуществлять кто-то другой. Для этого человека создаю в корневом каталоге приложения файл с именем README.md.

$ vim README.md

В этот файл я напишу следующий текст.

Как видно на снимке экрана, в тексте файла я разместил последовательность команд, с помощью которых восстановленную из Git-хранилища копию приложения можно будет правильно установить в систему. Сохраняю изменения в файл и покидаю текстовый редактор.

Инициализирую в корневом каталоге приложения новое Git-хранилище.

$ git init .

Добавляю всё содержимое корневого каталога в базу Git.

$ git add .

Давайте взглянем на статус только что созданного Git-хранилища.

$ git status

Как видно на снимке экрана выше, в Git попали все файлы и каталоги, которые создавал и редактировал я. Ни одно из исключений в этом списке не числится. Просмотреть все добавляемые в хранилище изменения этих файлов на текущем этапе можно с помощью вот такой команды.

$ git diff --staged

Все текущие изменения необходимо сохранить в Git, для этого фиксирую транзакцию.

$ git commit -m"Create webapp"

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

Синхронизация с Git-сервером

Поскольку уже в ближайшей перспективе я планирую развернуть это web-приложение на сервер сети Интернет, мне для этого потребуется сделать копию кода в файловую систему сервера. Кроме этого, вполне вероятно, что в команде появится frontend разработчик, которому тоже будет необходимо скопировать код в файловую систему своего рабочего компьютера. И чтобы все эти копии можно было синхронизировать между собой, разумным решением будет хранение копии кода приложения на Git-сервере.

В моём распоряжении есть профиль на github.com с установленным ключом SSH. В этом профиле и с помощью web-интерфейса сайта создаю новое абсолютно пустое хранилище с именем website, совпадающим с именем корневого каталога приложения. В результате этого сервис переместит меня на страницу только что созданного хранилища.

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

$ git remote add origin git@github.com:jazz4web/website.git

Изменяю имя главной ветки хранилища на main, по-умолчанию Git создаёт ветку master.

$ git branch -M main

И "запушиваю" единственный в текущей ветке commit на сервер github.com.

$ git push -u origin main

Поскольку я впервые подключаюсь к этом серверу с этим ключом, программа в интерактивном режиме запрашивает подтверждение на выполнение действия, ввожу в приглашение yes. Мой ключ SSH закрыт паролем, и поэтому следующим действием программа запрашивает ввод пароля, вот как выглядит подключение в моём терминале.

Следует обратить внимание, что при вводе пароль на терминале не отображается. После ввода пароля в выхлопе программы следует отчёт о количестве скопированных объектов. Всё, с этого момента копия кода хранится в публичном хранилище на сервере github.com. А все цели этой демонстрации полностью достигнуты.

Подводим промежуточный итог

Процесс разработки web-приложения достаточно сложен, растянут по времени и требует внимания и усидчивости. С этого момента управлять всеми изменениями кода будет система контроля версий Git. Копия кода теперь хранится в публичном хранилище на специализированном Git-сервисе, и с ней становится возможным синхронизировать все копии приложения соответствующими инструментами Git. Все подготовительные мероприятия таким образом можно считать завершенными, а в ближайшем выпуске этого цикла статей я покажу начальную вёрстку базового шаблона web-приложения.

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