![\"\"](\"https:\/\/maxkuznetsov.ru\/pictures\/gitflow.png\")
\n<\/div>\nОбщее<\/h2>\n
В нашем проекте ветка develop<\/b> — ветка, которая содержит стабильный результат, который можно зарелизить на прод.<\/p>\n
Следуя этому принципу, в рамках работы по спринту в ветку develop вливаются фичи\/задачи:<\/p>\n
- \n
- стабильного качества (по мнению разработчика (всегда) и менеджера (аппрув менеджера требуется, если этого требует конкретная задача);<\/li>\n
- из спринта, который в работе (то есть те задачи, которые должны быть в ближайшем релизе).<\/li>\n<\/ul>\n
Если ведется работа по фиче, которая не войдет в ближайший релиз, она не вливается в develop. Тестирование такой задачи можно проводить, подключая ветку фичи на свободную дев площадку (не вливая ее в develop ветку).<\/p>\n
Правила именования<\/h2>\n
Каждый коммит и пулл-реквест должны именоваться в следующем формате:<\/p>\n
\n
[Sentry] EDS-1004: <пояснение><\/p>\n<\/blockquote>\n
В квадратных скобках можно указать часть системы, которая затрагивается — это упростит поиск коммита, если что-то сломается. Списка частей системы нет, выбирайте на свой вкус. Из общих советов — это должно быть что-то широкое, чтобы был понятен контекст, но не слишком широкое, чтобы не терялся смысл.<\/p>\n
EDS-1004 — даёт понимание по какой задаче была изменена строка в кода (через git blame), а потом по задаче можно найти ПОЧЕМУ это было сделано.
\nПлюс почти все таск-трекеры позволяют сконнектиться с Gitlab\/Github\/etc, и тогда коммиты и ПРы будут показываться в таск-трекре. А в Gitlab\/Github все упоминания задач будут отображаться ссылками на таск-трекер автоматически.<\/p>\nРабота с ветками<\/h2>\n
- \n
- Из ветки main (или аналогичных prod\/master) создается ветка develop.<\/li>\n
- На каждую фичу создаётся новая ветка вида feature\/XXX-short-description от ветки develop. XXX — номер задачи из таск-трекера,
— краткое описание задачи на английском языке. Например: `feature\/TASK-1777-change-forms-for-clients`.<\/li>\n - Когда фича готова (это значит, что разработчик считает, что фича выполнена корректно и протестирована локально) ветка фичи отправляется через Пулл-реквест в ветку develop. При создании Пулл-реквеста обязательно нужно выбрать галку «удалить ветку после мерджа», чтобы не разводить кладбище веток в git.<\/li>\n
- Разработчик не забывает регулярно подтягивать ветку develop в свою ветку фичи в процессе разработки, чтобы уменьшить количество конфликтов при последующем MR в develop.<\/li>\n
- Для релиза ветку develop мерджим в ветку main через MR в Gitlab\/Githab\/etc.<\/li>\n
- Если в ветке prod обнаруживается критичный баг, то от main создается ветка hotfix\/XXX-short-description.<\/li>\n
- Как только исправление на ветке hotfix завершено, она мержится с ветками main, а затем с develop.<\/li>\n
- После каждого мерджа тестируем в первую очередь новый функционал, потом все остальное.<\/li>\n
- Если разработчик не успевает сделать свою задачу до релиза, то ветка фичи не мерджится в ветку develop.<\/li>\n
- Если фича большая и не попадает в ближайший релиз, то разработку продолжаем в той же ветке под фичу, пока ее полностью не сделаем. Не забываем делать git pull, чтобы подтягивать все изменения c ветки develop. Это позволит подтягивать все изменения текущего спринта и разрешать конфликты как можно быстрее. Свою задачу можно протестировать на стейдже, залив её туда без мерджа.<\/li>\n<\/ol>\n", "date_published": "2025-07-15T11:15:15+03:00", "date_modified": "2025-07-15T11:15:05+03:00", "image": "https:\/\/maxkuznetsov.ru\/pictures\/gitflow.png", "_date_published_rfc2822": "Tue, 15 Jul 2025 11:15:15 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "49", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/maxkuznetsov.ru\/pictures\/gitflow.png" ] } }, { "id": "48", "url": "https:\/\/maxkuznetsov.ru\/all\/kak-deploit-proekt-cherez-deployer\/", "title": "[Инструкция] Как деплоить проект через Deployer", "content_html": "
(Инструкция, которую приходится копировать из проекта в проект, поэтому пусть будет и в блоге.)<\/p>\n
Предполагается, что Deployer доступен уже в проекте, либо как файл `.\/dep`, либо как установленный composer пакет через `.\/vendor\/bin\/dep`. Он добавляется и хранится в гит-репозитории.<\/p>\n
Также важно настроить конфиги, указав хост в `.\/deploy.php`. Они также хранятся в репозитории.<\/p>\n
Обычные \/ регулярные деплои<\/h2>\n
`.\/dep deploy
`, где в качестве можно выбрать любой хост из deploy.php файла. В этом файле у хоста указана нужная ветка. Однако, делать это обычно не нужно, так как на проекте настрое Gitlab CI (см файл `.gitlab-ci.yaml`), который зарелизит код по коммиту.<\/p>\n Как сменить деплой-ветку для хоста<\/h2>\n
Предположим, вы хотите сменить на `dev` ветку с `develop` на `feature\/TASK-82-history-mypractice`.<\/p>\n
Простой и быстрый вариант для быстрых тестов<\/h3>\n
Вы можете это сделать, поменяв `→set(’branch’, ’feature\/TASK-82-history-mypractice’)` в deploy.php для хоста `dev`, а потом запустить `.\/dep deploy dev`.<\/p>\n
Этот способ хорош, если хочется быстро показать ветку, и мы не ожидаем, что будет много фиксов, так как Gitlab CI всё ещё останется настроен на `develop` ветку. И поэтому:<\/p>\n
- \n
- при коммите в `develop` ветку, Gitlab CI запустит `.\/dep deploy dev` и задеплоит `feature\/TASK-82-history-mypractice` на `dev`. Но это неправильно, так как мы не хотим деплоить эту ветку на дев по коммиту в `develop`, мы хотим деплоить по коммиту в ветку `feature\/TASK-82-history-mypractice`<\/li>\n
- при коммите в `feature\/TASK-82-history-mypractice` ветку CI ничего не сделает, так как в версии конфига `.gitlab-ci.yaml` из этой ветки нет никакого правила для ветки `feature\/TASK-82-history-mypractice`.<\/li>\n<\/ul>\n
Правильный вариант с обновлением Gitlab CI правил<\/h3>\n
- \n
- Переключиться в `develop` ветку, изменить branch в deploy.php для нужного хоста и в `.gitlab-ci.yaml` изменить параметр `only:` для этого же хоста.<\/li>\n
- Закоммитить. CI теперь не запустит деплой на `dev`, так как мы поменяли ветку на `feature\/TASK-82-history-mypractice`.<\/li>\n
- Переключиться в ветку `feature\/TASK-82-history-mypractice` в git и вмерджить в неё свежий `develop`. Вместе с develop придут изменения для `deploy.php` и `.gitlab-ci.yaml`. Поэтому если сразу закоммитить вмёрдженное, то Gitlab CI запустит деплой feature-ветки на `dev`.<\/li>\n
- Важно! Перед мерджем ветки в `develop` нужно изменить `deploy.php` и `.gitlab-ci.yaml` и заменить feature-ветку в них обратно на `develop`. Потом смерджить и Gitlab CI, увидев этот коммит в develop, сразу продеплоит `develop` на `dev`.<\/li>\n<\/ol>\n
Как переключить хост с feature1-ветки на другую feature-2 ветку:<\/h3>\n
- \n
- Переключиться в develop ветку и изменить в ней `deploy.php` и `.gitlab-ci.yaml`, указав feature2 вместо feature1 для нужного хоста.<\/li>\n
- Вмерджить develop ветку сначала в feature1 ветку, потом в feature2 ветку.<\/li>\n<\/ol>\n
Удобные команды<\/h2>\n
- \n
- `.\/dep ssh
` — команда подключится к хосту по конфигу из deploy.php и сделает перейдёт в папку current релиза.<\/li>\n - `.\/dep run «
»` — запускает команду на удалённых серверах. После запуска она спросит на каких серверах запустить.<\/li>\n - `.\/dep
` — запускает любую определённую в deploy.php `task(’ ’, )` на нужно сервере.<\/li>\n - Можно указать «теги» для серверов и запускать всё выше написанное сразу пачками.<\/li>\n<\/ol>\n
Первый деплой \/ создание окружения<\/h2>\n
- \n
- `.\/dep deploy develop2` — первый раз закончится с ошибкой, но Deployer создаст структуру файлов по пути из deploy.php для develop2. Он создаст папки\n
- \n
- `\/var\/www\/dev.project.name\/releases` — тут будут располагаться папки с каждым новым релизом и копиться последние N штук.<\/li>\n
- `\/var\/www\/dev.project.name\/shared` — тут хранятся файлы, которые должны быть сохранены и перенесены между релизами. Например, логи, web\/assets, storage, etc. Эти папки задаются в deploy.php как shared_folder и shared_files. Во время деплоя эти папки будут заменены на симлинки из shared папки.<\/li>\n
- `\/var\/www\/dev.project.name\/current` — симлинк на последний успешный релиз из папки releases.<\/li>\n<\/ol>\n<\/li>\n
- После создания структуры нужно перенести\/создать файлы в shared:\n
- \n
- `.\/shared\/.env`<\/li>\n
- `.\/shared\/web\/XXXXXXX` — можно посмотреть, какие папки создадутся на сервере, либо какие папки указаны в shared_folder в deploy.php (с учётом тех, что указаны во фреймворк-специфичном recipe, подключённом в deploy.php).<\/li>\n<\/ol>\n<\/li>\n
- Повторить деплой `.\/dep deploy develop2`<\/li>\n
- Также нужно залить данные в БД \/ импортнуть из sql дампа по параметрам из `.env`.<\/li>\n<\/ol>\n",
"date_published": "2025-07-15T10:54:36+03:00",
"date_modified": "2025-07-15T10:56:42+03:00",
"_date_published_rfc2822": "Tue, 15 Jul 2025 10:54:36 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "48",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "44",
"url": "https:\/\/maxkuznetsov.ru\/all\/ubuntu-systemd-systemctl-on-startup\/",
"title": "Как добавить новый сервис в systemd\/systemctl и запускать его при старте Ubuntu",
"content_html": "
Задача<\/h3>\n
Есть docker-compose файл, поднимающий Zabbix. Есть небольшая обёртка в виде Makefile, которая позволяет запускать и останавливать docker-compose. Нужно добавить запуск этой команды при старте\/рестарте системы.<\/p>\n
Дано<\/h3>\n
Всё лежит в `\/var\/www\/zabbix-server\/`.
\nСодержание файла Makefile:<\/p>\n...\r\ndocker-up:\r\n docker-compose up -d\r\n\r\ndocker-down:\r\n docker-compose stop<\/code><\/pre>Решение<\/h3>\n
- \n
- Создать новый файл `vim \/etc\/systemd\/system\/zabbix.service`.<\/li>\n<\/ol>\n
[Unit]\r\nDescription=Run Zabbix Docker Containers on Startup\r\n\r\n[Service]\r\nRemainAfterExit=True\r\nRestart=always\r\nRestartSec=1\r\nWorkingDirectory=\/var\/www\/zabbix-server\r\nExecStart=\/usr\/bin\/make docker-up\r\nExecStop=\/usr\/bin\/make docker-down\r\n\r\n[Install]\r\nWantedBy=default.target<\/code><\/pre>- \n
- chmod 644 \/etc\/systemd\/system\/zabbix.service<\/li>\n
- systemctl enable zabbix.service<\/li>\n
- systemctl start zabbix.service<\/li>\n<\/ol>\n",
"date_published": "2023-05-10T17:35:55+03:00",
"date_modified": "2023-05-10T17:35:51+03:00",
"_date_published_rfc2822": "Wed, 10 May 2023 17:35:55 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "44",
"_e2_data": {
"is_favourite": false,
"links_required": [
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css",
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css",
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css",
"system\/library\/highlight\/highlight.js",
"system\/library\/highlight\/highlight.css"
],
"og_images": []
}
},
{
"id": "35",
"url": "https:\/\/maxkuznetsov.ru\/all\/vim-1minute-boost\/",
"title": "Как прокачать Vim за 1 минуту",
"content_html": "
Можно долго спорить о лучших IDE и редакторах для разработки кода, но если вы работаете в консоли или подключаетесь к серверу по SSH, то удобнее vim ничего нет. Он установлен по умолчанию на большинстве хостингов, так что имеет смысл его изучить и полюбить.<\/p>\n
Настройка vim происходит в файле ~\/.vimrc. Его может не быть, это нормально, тогда нужно создать.<\/p>\n
- \n
- Открываем ~\/.vimrc<\/li>\n<\/ol>\n
$ vim ~\/.vimrc<\/code><\/pre>- \n
- Добавляем в файл следующее содержимое и сохраняем (команда «:wq»):<\/li>\n<\/ol>\n
set ttyfast\r\nset showmode\r\nset showcmd\r\nset title\r\nset hidden\r\nset ffs=unix,dos,mac\r\n\r\n" Показывать нумерацию строк\r\nset number\r\n\r\n" Чтобы не было проблем с swp-файлами, которые создаются во время редактирования\r\nset nobackup\r\nset nowritebackup\r\nset nowb\r\nset noswapfile\r\n\r\n" Глубина истории\r\nset undolevels=1000\r\n\r\nsyntax on\r\n" Цветовая схема\r\nset t_Co=256\r\n\r\n" monokai не идёт по умолчанию, но мы его установим чуть позже\r\ncolorscheme monokai\r\n\r\n" Рисовать вертикальную линию для отображения границы в 120 символов — строки длинее хуже читаются\r\nset colorcolumn=120\r\nhighlight ColorColumn ctermbg=238 guibg=#232728\r\n\r\n" Настройка табов\r\nset expandtab\r\nset tabstop=4\r\nset shiftwidth=4\r\n\r\n" Отображать скрытые символы, табы и висящие пробелы\r\nset list\r\nset listchars=tab:→\\ ,trail:·,nbsp:·<\/code><\/pre>- \n
- Я использую тёмную тему monokai. Её нет среди тем по умолчанию, но установить её несложно:<\/li>\n<\/ol>\n
ls —l \/usr\/share\/vim\/vim*\/colors<\/b> покажет все предустановленные в системе темы<\/p>\n
$ mkdir -p ~\/.vim\/colors\r\n$ curl -o ~\/.vim\/colors\/monokai.vim https:\/\/raw.githubusercontent.com\/sickill\/vim-monokai\/master\/colors\/monokai.vim<\/code><\/pre>Имя этого файла с темой нужно указать в ~\/.vimrc в строке<\/p>\n
colorscheme <monokai><\/code><\/pre>", "date_published": "2020-05-28T19:02:48+03:00", "date_modified": "2020-10-25T01:51:40+03:00", "_date_published_rfc2822": "Thu, 28 May 2020 19:02:48 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "35", "_e2_data": { "is_favourite": false, "links_required": [ "system\/library\/highlight\/highlight.js", "system\/library\/highlight\/highlight.css", "system\/library\/highlight\/highlight.js", "system\/library\/highlight\/highlight.css", "system\/library\/highlight\/highlight.js", "system\/library\/highlight\/highlight.css", "system\/library\/highlight\/highlight.js", "system\/library\/highlight\/highlight.css", "system\/library\/highlight\/highlight.js", "system\/library\/highlight\/highlight.css", "system\/library\/highlight\/highlight.js", "system\/library\/highlight\/highlight.css", "system\/library\/highlight\/highlight.js", "system\/library\/highlight\/highlight.css", "system\/library\/highlight\/highlight.js", "system\/library\/highlight\/highlight.css" ], "og_images": [] } }, { "id": "13", "url": "https:\/\/maxkuznetsov.ru\/all\/console-iterm2-omyzsh\/", "title": "Как улучшить терминал в Mac OS X: iTerm2, omyzsh, zsh", "content_html": "Отличная статья про апгрейд встроенного Terminal
\nhttps:\/\/medium.com\/@Clovis_app\/configuration-of-a-beautiful-efficient-terminal-and-prompt-on-osx-in-7-minutes-827c29391961<\/a><\/p>\nКраткий план действий<\/h2>\n
- \n
- Ставим iTerm2 на замену Terminal. Они нормально сосуществуют и можно будет откатиться, если не понравится.<\/li>\n<\/ol>\n
brew cask install iterm2<\/code><\/pre>- \n
- Ставим цветовую cхему<\/a> для iTerm2 (сохраняйте именно как .itermcolors) — это набор цветов и ничего больше. На данном этапе терминал всё ещё будет выглядеть уныло.<\/li>\n
- Качаем шрифт с поддержкой дополнительных символов-иконок: обычный<\/a> или жирный<\/a> (он контрастнее) — и устанавливаем в систему. Иначе увидим не иконки, а пустые квадратики.
\nМеняем размер шрифта на 12-14pt или какой удобнее.<\/li>\n- Через консоль iTerm’a устанавливаем Zsh (вместо стандартного Bash) и Oh my Zsh — само ядро командной строки и оболочку с форматированием вокруг неё.<\/li>\n<\/ol>\n
# Возможно, zsh у вас уже есть по умолчанию. Чтобы проверить, нужно ввести : \r\nwhich zsh\r\n# Если вернёт путь, значит есть. Если нет, то ставим:\r\nbrew install zsh zsh-completions\r\n# Устанавливаем Oh my Zsh\r\nsh -c "$(curl -fsSL https:\/\/raw.github.com\/robbyrussell\/oh-my-zsh\/master\/tools\/install.sh)"<\/code><\/pre>- \n
- Важно: теперь основной конфигурационный файл консоли — ~\/.zshrc, а не ~\/.bashrc или ~\/.bash_profile.<\/li>\n
- Скачиваем в дефолтную директорию тему — самую маковку, которая добавит красоты в терминал<\/li>\n<\/ol>\n
git clone https:\/\/github.com\/bhilburn\/powerlevel9k.git ~\/.oh-my-zsh\/custom\/themes\/powerlevel9k\r\n# Редактируем ~\/.zshrc и меняем конфиг\r\nZSH_THEME="powerlevel9k\/powerlevel9k"<\/code><\/pre>- \n
- Перезагружаем iTerm и вуаля.<\/li>\n<\/ol>\n
Улучшение вида и поведения терминала<\/h2>\n
- \n
- Вид самой строки<\/li>\n<\/ol>\n
POWERLEVEL9K_LEFT_PROMPT_ELEMENTS=(dir rbenv vcs)\r\nPOWERLEVEL9K_RIGHT_PROMPT_ELEMENTS=(status root_indicator background_jobs history time)\r\nPOWERLEVEL9K_VCS_MODIFIED_BACKGROUND='red' # Будет менять цвет, если есть обновления в гит-репозитории<\/code><\/pre>- \n
- Я не стал делать перенос строки (POWERLEVEL9K_PROMPT_ON_NEWLINE=true), так как у меня терминал всегда на всю ширину экрана и места хватает.<\/li>\n
- Обязательно: iTerm → Preferences → Profiles → Keys → Load Preset… → Natural Text Editing, чтобы работала навигация через Option + стрелки и прочее.<\/li>\n
- Можно добавить автодополнение команд на основе истории<\/li>\n<\/ol>\n
git clone https:\/\/github.com\/zsh-users\/zsh-autosuggestions $ZSH_CUSTOM\/plugins\/zsh-autosuggestions\r\nvim ~\/.zshrc\r\n# Внутри файла добавляем через пробел название плагина\r\nplugins=(… zsh-autosuggestions)<\/code><\/pre>
- Вид самой строки<\/li>\n<\/ol>\n
- Перезагружаем iTerm и вуаля.<\/li>\n<\/ol>\n
- Качаем шрифт с поддержкой дополнительных символов-иконок: обычный<\/a> или жирный<\/a> (он контрастнее) — и устанавливаем в систему. Иначе увидим не иконки, а пустые квадратики.
- Ставим цветовую cхему<\/a> для iTerm2 (сохраняйте именно как .itermcolors) — это набор цветов и ничего больше. На данном этапе терминал всё ещё будет выглядеть уныло.<\/li>\n
- Ставим iTerm2 на замену Terminal. Они нормально сосуществуют и можно будет откатиться, если не понравится.<\/li>\n<\/ol>\n
- Я использую тёмную тему monokai. Её нет среди тем по умолчанию, но установить её несложно:<\/li>\n<\/ol>\n
- Добавляем в файл следующее содержимое и сохраняем (команда «:wq»):<\/li>\n<\/ol>\n
- Открываем ~\/.vimrc<\/li>\n<\/ol>\n
- Создать новый файл `vim \/etc\/systemd\/system\/zabbix.service`.<\/li>\n<\/ol>\n
- `.\/dep run «
- `.\/dep ssh