Skip to content

Latest commit

 

History

History
446 lines (300 loc) · 20.1 KB

README.md

File metadata and controls

446 lines (300 loc) · 20.1 KB

Диплом

Automated tests CoverageDuplicated Lines (%) BugsCode Smells


Duplicated Lines (%) Lines of CodeReliability Rating VulnerabilitiesSecurity Rating Maintainability Rating

Оглавление(ссылки)


Данные для входа

Приложение Локально Сайт
логин karlik karlik_01
пароль terpenie terpenie_01
вход читать гайд mrs.hopto.org (если работает)
94.139.242.71
админ-панель admin terpenie

Заметки по проекту:

Вот таким образом можно делать заметки в коде(работает в pycharm точно)

/# TODO: task (использовать без /)

После принятия и слияния PR, в которых вносились изменения в models, требуется принять миграции.

python manage.py migrate

Иначе могут быть проблемы.

Команды проекта

Импорт данных из файл excel

python manage.py excel_import <patch>

Имена и пол генерирует с помощью faker
Данные же берет из строки в файле важно, чтобы столбцы назывались также, как и соответствующие поля в модели

Заполнение тестовых записей в базу данных

Добавлен функционал для заполнения базы тестовыми записями. Работает на _faker, чтобы вызвать и добавить нужно использовать команду:

python manage.py populate_data <кол-во>

Через аргумент передаём кол-во записей для создания. Минимум 1, максимум 100

пример

python manage.py populate_data 40

Будет создано 40 новых записей

Сохранение файла с данными бд локально

Команда для выгрузки данных из базы.

Принимает следующие аргументы:

--all - взять всё --format для выбора формата файла, есть:

  • json
  • excel
  • csv
  • xml
    чтобы взять всё:

--all
чтобы взять выборочно: (список id)

python manage.py download_client_data --format json --all

или так:

python manage.py download_client_data --format excel fb8e1387-6019-4b99-af9e-fcfd87e24aee

Гайд по ведению гита проекта

В main находится стабильная версия, которая будет работать на сервере.
Чтобы что-то сделать, нужно создать ветку от main'a и назвать дать ей соответствующее название.
Дальше работаем в ветке и делаем нормальные коммиты(гайд есть ниже).
Далее, чтобы применить изменения, нужно сделать пулл-реквест в main.
Далее требуется подтверждение от коллег и пройти тесты SonarCloud.

Гайд по названиям веток:

Создание новой ветки:

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

feature/ для новых функциональностей
bugfix/ для исправлений ошибок
chore/ для задач, не связанных напрямую с функциональностью или исправлением бага, например, обновление зависимостей

Например:

git checkout -b feature/new-feature
git checkout -b bugfix/fix-bug
git checkout -b chore/update-dependencies


Работа с веткой:

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

Синхронизация с удаленным репозиторием:

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

Пулл-реквест:

При создании пулл-реквеста убедитесь, что ваша ветка называется согласно соглашениям. Если есть проблемы с названием ветки, система выдаст соответствующее сообщение об ошибке.


Гайд по названиям коммитов:

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

Префиксы для коммитов:

fix: Исправление ошибки в модуле X
feat: Добавление функциональности Y
docs: Обновление инструкций по установке
refactor: Переименование переменных для улучшения читаемости
style: Коррекция отступов и стиля кода
test: Добавление модульных тестов для класса Z
update: Обновление функционала
docs: Добавление информации в документацию версии 1

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

git commit -m "feat: добавлена новая функциональность"
git commit -m "fix: исправлена ошибка в обработке данных"
git commit -m "chore: обновление зависимостей"

Логическая связь:

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

Обновление коммитов:

Если вы заметили, что название коммита не соответствует соглашениям, вы можете внести исправления и использовать git commit --amend для изменения последнего коммита.


Гайд по названиям PR:

Правила и примеры использования префиксов в названиях Pull Request (PR)

fix: Используется для PR, в котором вносятся исправления ошибок.
feat: добавление новой функциональности
docs: обновление документации
refactor: Используется для PR, связанного с переработкой кода без добавления новой функциональности или исправлений.
style: форматирование кода в соответствии с Prettier
test: Используется для PR, связанного с добавлением или обновлением тестов.
update: обновление зависимостей или других внешних компонентов.


Гайд по структуре проекта

Проект состоит из двух приложений:

web_hanlder

Login
Home
Прочие информационные страницы, не связанные с обработкой

clients

clients_list
clients_details

Тут все записи. Нейронка будет либо тут, либо еще одно приложение. Посмотрим.

Окружение


Проект переведен на python3 12 версии. Подойдет версия начиная с 3.12.1

Узнать версию python:

python --version

Скачать: https://www.python.org/ftp/python/3.12.1/python-3.12.1-amd64.exe

Также нужно обновить и пакетный менеджер (PIP):

python -m pip install --upgrade pip

Чтобы работать, нужно создать виртуальное окружение - это изолированное окружение среды (в нашем случае это окружение Python), которое позволяет нам использовать определенные версии приложений.

в консоли -> Заходим в нужную папку -> пишем:

python -m venv venv  

ВАЖНО
Нужно обязательно проверять включен venv или нет!

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

Установить все зависимости для проекта:

pip install -r requirements.txt

Чтобы запустить:

переходим в venv\Scripts запускаем activate на windows: ./activate Всё работает, что бы выйди -> Deactivate

_Если что-то нужно еще, то устанавливаем и предупреждаем! Гайд по зависимостям будет чуть позже.


Запуск

Нужно быть в файле проекта. То есть не просто в папке Diplom, а в mrs_proj, где находится файл manage.py

python manage.py runserver

Если всё нормально, то запуститься на localhost:8000, также можно передать аргументом нужный порт.

Закрыть проект:

CTRL+C  в консоль

Работая локально, вы работаете через базу Sqlite, которая тягается с проектом.


Работа с файлами

Есть соглашение, чтобы все статические(css, js, картинки и прочее) лежали в папке static нужного приложения(допускаются вложения отдельных папок)

стиль описания файлов:

приложение_страница_приложения_тип

Пример:

clients_list_styles.css

Если есть два слова, типа web_handler. То можно использовать сокращение или одно слово. Главное чтобы везде было одинаково.


Шаблонизатор

Шаблонизатор — программное обеспечение, позволяющее использовать html-шаблоны для генерации конечных html-страниц. Основная цель использования шаблонизатора — это отделение представления данных от исполняемого кода.

Подключения статических файлов:

{% load static %}
{% static "путь к файлу внутри папки static" %}
<link rel="stylesheet" href="{% static " css/styles.css" %}" />

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

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

Например, определим шаблон, который назовем base.html:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8"/>
    <title>{% block title %}Default title{% endblock title %}</title>
</head>
<body>
<div><a href="/">Главная</a> | <a href="/contacts">Контакты</a></div>
<h1>{% block header %}{% endblock header %}</h1>
<div>{% block content%}{% endblock content %}</div>
<div>MyCorp. 2022. All rights reserved.</div>
</body>
</html>

С помощью элементов {% block название_блока %}{% endblock название_блока %} определяются отдельные блоки шаблонов. При этом для каждого блока определяется открывающий элемент {% block название_блока %} и закрывающий элемент {% endblock название_блока %}.

Теперь применим этот базовый шаблон. Например, создадим новый шаблон index.html:

{% extends "base.html" %}
{% block title %}Index{% endblock title %}
{% block header %}Главная{% endblock header %}

Также создадим шаблон contacts.html:

{% extends "base.html" %}
{% block title %}Контакты{% endblock title %}
{% block header %}Контакты{% endblock header %}

{% block content %}
<p>Телефон: +12345677890</p>
<p>Email: [email protected]</p>
{% endblock content %}

Тесты

В приложении работают авто-тесты. Нужно обязательно смотреть за покрытием нового кода тестами. Тесты дописываются в соответствующие файлы проекта. tests.py Документация по тестам есть в документации Django.

Сейчас есть два варианта запустить тесты

(директория /mrs_proj)

python manage.py test

Запуск тестов с покрытием:

tox

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

При PR SonarCloud будет запускать тесты у себя. Так что если что-то будет не так, то ошибки смотрим на Github.


Docker

Сделал настройки для сбора приложения в докер-контейнер. Там сразу все настройки. Nginx и Gunicorn. Версия приложения собирается последняя стабильная. Естественно нужен установленный docker в системе.

docker build -t mrs_proj:latest .  #собрать контейнер
docker save -o mrs_proj_image.tar mrs_proj:latest # экспорт Docker-образа и перенос на другую машину

Перенесите файл mrs_proj_image.tar на другую машину.

docker load -i mrs_proj_image.tar # импортируйте Docker-образ на другой машине

Запустить контейнер

docker run -p 8000:8000 mrs_proj:latest gunicorn mrs_proj.wsgi:application

Замените 8000:8000 на необходимые вам порты, и убедитесь, что ваши Django-настройки (например, ALLOWED_HOSTS)
и настройки Gunicorn соответствуют вашему окружению.
Теперь ваш Django проект должен быть доступен на порту 8000 внутри контейнера.


nonlin