#Devops для аналитиков
Решил я немного погрузиться в основы деплоя и раскатки ПО. Во-первых, у нас на проекте свои полноценные Devops-практики сблекджеком GitLab и CI/CD, да к тому же одна из моих задач сейчас связана с разработкой софтины по мониторингу работоспособности камер, а также с некоторыми сервисными операциями по восстановлению работоспособности отдельных камер. Среди нужных фичей там актуализация Docker-образов, перезапуск контейнеров и всякое такое... Короче, предлагаю сегодня в связи с этой темой посмотреть, какие файлики должны быть в папке с проектом, чтобы задеплоить и развернуть твой 😄
Итак, что у нас может быть в папке с проектом.
👩💻 Docker файлы
‣
‣
‣
‣
👩💻 CI/CD (GitLab)
‣
‣
👩💻 Git и документация
‣
‣
‣
‣
🛠 Конфигурация
‣
‣
‣
👩💻 Python
‣
‣
‣
‣
‣
‣
👩💻 Rust (ну раз уж он у нас тоже на проекте есть)
‣
‣
🎯 Что все это дело дает для деплоя:
1. Сборка → Dockerfile + docker-compose;
2. Тестирование → .gitlab-ci.yml + env.tests;
3. Деплой → .gitlab-ci.yml + k8s-cronjob.yaml;
4. Настройка → config.yml + переменные окружения.
In conclusion: у каждого в команде своя роль и своя специализация, но системный аналитик должен разбираться во всех этапах разработки ПО и ввода его в эксплуатацию (в том числе иметь представление, как работают Devops-инженеры).
#DevOps #системныйанализ #работа #docker #python
Решил я немного погрузиться в основы деплоя и раскатки ПО. Во-первых, у нас на проекте свои полноценные Devops-практики с
print("Hello World") с оркестрацией и релизным пайплайном. Итак, что у нас может быть в папке с проектом.
‣
Dockerfile — инструкция для сборки Docker-образа;‣
docker-compose.yml — запуск нескольких контейнеров вместе;‣
docker-compose.dev.yml — версия для разработки;‣
.dockerignore — что НЕ копировать в Docker-образ.‣
.gitlab-ci.yml — пайплайн автоматической сборки, тестов, деплоя;‣
k8s-cronjob.yaml — задания по расписанию в Kubernetes.‣
.gitignore — какие файлы игнорировать в Git;‣
.gitattributes — настройки обработки файлов в Git;‣
README.md — документация проекта;‣
.ipynb — Jupyter notebook с примерами/анализом.🛠 Конфигурация
‣
config.yml — общие настройки приложения;‣
.local.env.tests, env.tests — переменные окружения для тестов;‣
lockalhost_local_start.sh — скрипт для запуска локально.‣
.python-version — какая версия Python используется;‣
.pylintrc — настройки линтера (проверка качества кода);‣
mypy.ini — настройки статической типизации;‣
pip.conf — настройки менеджера пакетов pip;‣
logging.conf — настройки логирования;‣
.pyarmor_config — настройки обфускации кода.‣
Cargo.toml - зависимости и настройки проекта (как requirements.txt);‣
Cargo.lock - точные версии зависимостей (генерируется автоматически).🎯 Что все это дело дает для деплоя:
1. Сборка → Dockerfile + docker-compose;
2. Тестирование → .gitlab-ci.yml + env.tests;
3. Деплой → .gitlab-ci.yml + k8s-cronjob.yaml;
4. Настройка → config.yml + переменные окружения.
In conclusion: у каждого в команде своя роль и своя специализация, но системный аналитик должен разбираться во всех этапах разработки ПО и ввода его в эксплуатацию (в том числе иметь представление, как работают Devops-инженеры).
#DevOps #системныйанализ #работа #docker #python
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍2⚡1
Честно скажу, я совсем недавно узнал, как это на самом деле называется: Feature Flag. Я, в общем-то, всегда звал это просто — рубильник.
Фича-флаг, он же Feature Toggle, а также Feature Flag
Ну грубо говоря как-то так:
if feature_flag.is_enabled('new_payment_system'):
use_new_payment()
else:
use_old_payment()После того, как по моим постановкам пару раз положили прод там, где лучше бы этого было не делать, я начал частенько прописывать необходимость рубильника.
Зачем вообще это все нужно?
Какие есть способы дернуть рубильник?
Что важно учитывать:
In conclusion: Фича-флаги — это не просто технический инструмент, это стратегия безопасной поставки изменений.
#SystemAnalysis #FeatureFlags #Разработка #python #IT #businessanalysis
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥2✍1