(Это инструкция, которую приходится копировать из проекта в проект, поэтому размещаю и в блоге.)

Gitflow

Идейно система работы с ветками берётся из Gitflow, но с упрощениями.

Общее

В нашем проекте ветка develop — ветка, которая содержит стабильный результат, который можно зарелизить на прод.

Следуя этому принципу, в рамках работы по спринту в ветку develop вливаются фичи/задачи:

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

Если ведется работа по фиче, которая не войдет в ближайший релиз, она не вливается в develop. Тестирование такой задачи можно проводить, подключая ветку фичи на свободную дев площадку (не вливая ее в develop ветку).

Правила именования

Каждый коммит и пулл-реквест должны именоваться в следующем формате:

[Sentry] EDS-1004: <пояснение>

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

EDS-1004 — даёт понимание по какой задаче была изменена строка в кода (через git blame), а потом по задаче можно найти ПОЧЕМУ это было сделано.
Плюс почти все таск-трекеры позволяют сконнектиться с Gitlab/Github/etc, и тогда коммиты и ПРы будут показываться в таск-трекре. А в Gitlab/Github все упоминания задач будут отображаться ссылками на таск-трекер автоматически.

Работа с ветками

1. Из ветки main (или аналогичных prod/master) создается ветка develop.
2. На каждую фичу создаётся новая ветка вида feature/XXX-short-description от ветки develop. XXX — номер задачи из таск-трекера,  — краткое описание задачи на английском языке. Например: `feature/TASK-1777-change-forms-for-clients`.
3. Когда фича готова (это значит, что разработчик считает, что фича выполнена корректно и протестирована локально) ветка фичи отправляется через Пулл-реквест в ветку develop. При создании Пулл-реквеста обязательно нужно выбрать галку «удалить ветку после мерджа», чтобы не разводить кладбище веток в git.
4. Разработчик не забывает регулярно подтягивать ветку develop в свою ветку фичи в процессе разработки, чтобы уменьшить количество конфликтов при последующем MR в develop.
5. Для релиза ветку develop мерджим в ветку main через MR в Gitlab/Githab/etc.
6. Если в ветке prod обнаруживается критичный баг, то от main создается ветка hotfix/XXX-short-description.
7. Как только исправление на ветке hotfix завершено, она мержится с ветками main, а затем с develop.
8. После каждого мерджа тестируем в первую очередь новый функционал, потом все остальное.
9. Если разработчик не успевает сделать свою задачу до релиза, то ветка фичи не мерджится в ветку develop.
10. Если фича большая и не попадает в ближайший релиз, то разработку продолжаем в той же ветке под фичу, пока ее полностью не сделаем. Не забываем делать git pull, чтобы подтягивать все изменения c ветки develop. Это позволит подтягивать все изменения текущего спринта и разрешать конфликты как можно быстрее. Свою задачу можно протестировать на стейдже, залив её туда без мерджа.

(Инструкция, которую приходится копировать из проекта в проект, поэтому пусть будет и в блоге.)

Предполагается, что Deployer доступен уже в проекте, либо как файл `./dep`, либо как установленный composer пакет через `./vendor/bin/dep`. Он добавляется и хранится в гит-репозитории.

Также важно настроить конфиги, указав хост в `./deploy.php`. Они также хранятся в репозитории.

Обычные / регулярные деплои

`./dep deploy `, где в качестве можно выбрать любой хост из deploy.php файла. В этом файле у хоста указана нужная ветка. Однако, делать это обычно не нужно, так как на проекте настрое Gitlab CI (см файл `.gitlab-ci.yaml`), который зарелизит код по коммиту.

Как сменить деплой-ветку для хоста

Предположим, вы хотите сменить на `dev` ветку с `develop` на `feature/TASK-82-history-mypractice`.

Простой и быстрый вариант для быстрых тестов

Вы можете это сделать, поменяв `→set(’branch’, ’feature/TASK-82-history-mypractice’)` в deploy.php для хоста `dev`, а потом запустить `./dep deploy dev`.

Этот способ хорош, если хочется быстро показать ветку, и мы не ожидаем, что будет много фиксов, так как Gitlab CI всё ещё останется настроен на `develop` ветку. И поэтому:

• при коммите в `develop` ветку, Gitlab CI запустит `./dep deploy dev` и задеплоит `feature/TASK-82-history-mypractice` на `dev`. Но это неправильно, так как мы не хотим деплоить эту ветку на дев по коммиту в `develop`, мы хотим деплоить по коммиту в ветку `feature/TASK-82-history-mypractice`
• при коммите в `feature/TASK-82-history-mypractice` ветку CI ничего не сделает, так как в версии конфига `.gitlab-ci.yaml` из этой ветки нет никакого правила для ветки `feature/TASK-82-history-mypractice`.

Правильный вариант с обновлением Gitlab CI правил

1. Переключиться в `develop` ветку, изменить branch в deploy.php для нужного хоста и в `.gitlab-ci.yaml` изменить параметр `only:` для этого же хоста.
2. Закоммитить. CI теперь не запустит деплой на `dev`, так как мы поменяли ветку на `feature/TASK-82-history-mypractice`.
3. Переключиться в ветку `feature/TASK-82-history-mypractice` в git и вмерджить в неё свежий `develop`. Вместе с develop придут изменения для `deploy.php` и `.gitlab-ci.yaml`. Поэтому если сразу закоммитить вмёрдженное, то Gitlab CI запустит деплой feature-ветки на `dev`.
4. Важно! Перед мерджем ветки в `develop` нужно изменить `deploy.php` и `.gitlab-ci.yaml` и заменить feature-ветку в них обратно на `develop`. Потом смерджить и Gitlab CI, увидев этот коммит в develop, сразу продеплоит `develop` на `dev`.

Как переключить хост с feature1-ветки на другую feature-2 ветку:

1. Переключиться в develop ветку и изменить в ней `deploy.php` и `.gitlab-ci.yaml`, указав feature2 вместо feature1 для нужного хоста.
2. Вмерджить develop ветку сначала в feature1 ветку, потом в feature2 ветку.

Удобные команды

1. `./dep ssh ` — команда подключится к хосту по конфигу из deploy.php и сделает перейдёт в папку current релиза.
2. `./dep run «»` — запускает команду на удалённых серверах. После запуска она спросит на каких серверах запустить.
3. `./dep ` — запускает любую определённую в deploy.php `task(’’, )` на нужно сервере.
4. Можно указать «теги» для серверов и запускать всё выше написанное сразу пачками.

Первый деплой / создание окружения

1. `./dep deploy develop2` — первый раз закончится с ошибкой, но Deployer создаст структуру файлов по пути из deploy.php для develop2. Он создаст папки
   1. `/var/www/dev.project.name/releases` — тут будут располагаться папки с каждым новым релизом и копиться последние N штук.
   2. `/var/www/dev.project.name/shared` — тут хранятся файлы, которые должны быть сохранены и перенесены между релизами. Например, логи, web/assets, storage, etc. Эти папки задаются в deploy.php как shared_folder и shared_files. Во время деплоя эти папки будут заменены на симлинки из shared папки.
   3. `/var/www/dev.project.name/current` — симлинк на последний успешный релиз из папки releases.
2. После создания структуры нужно перенести/создать файлы в shared:
   1. `./shared/.env`
   2. `./shared/web/XXXXXXX` — можно посмотреть, какие папки создадутся на сервере, либо какие папки указаны в shared_folder в deploy.php (с учётом тех, что указаны во фреймворк-специфичном recipe, подключённом в deploy.php).
3. Повторить деплой `./dep deploy develop2`
4. Также нужно залить данные в БД / импортнуть из sql дампа по параметрам из `.env`.

Задача

Есть docker-compose файл, поднимающий Zabbix. Есть небольшая обёртка в виде Makefile, которая позволяет запускать и останавливать docker-compose. Нужно добавить запуск этой команды при старте/рестарте системы.

Дано

Всё лежит в `/var/www/zabbix-server/`.
Содержание файла Makefile:

...
docker-up:
        docker-compose up -d

docker-down:
        docker-compose stop

Решение

1. Создать новый файл `vim /etc/systemd/system/zabbix.service`.

[Unit]
Description=Run Zabbix Docker Containers on Startup

[Service]
RemainAfterExit=True
Restart=always
RestartSec=1
WorkingDirectory=/var/www/zabbix-server
ExecStart=/usr/bin/make docker-up
ExecStop=/usr/bin/make docker-down

[Install]
WantedBy=default.target

2. chmod 644 /etc/systemd/system/zabbix.service
3. systemctl enable zabbix.service
4. systemctl start zabbix.service

Можно долго спорить о лучших IDE и редакторах для разработки кода, но если вы работаете в консоли или подключаетесь к серверу по SSH, то удобнее vim ничего нет. Он установлен по умолчанию на большинстве хостингов, так что имеет смысл его изучить и полюбить.

Настройка vim происходит в файле ~/.vimrc. Его может не быть, это нормально, тогда нужно создать.

1. Открываем ~/.vimrc

$ vim ~/.vimrc

2. Добавляем в файл следующее содержимое и сохраняем (команда «:wq»):

set ttyfast
set showmode
set showcmd
set title
set hidden
set ffs=unix,dos,mac

" Показывать нумерацию строк
set number

" Чтобы не было проблем с swp-файлами, которые создаются во время редактирования
set nobackup
set nowritebackup
set nowb
set noswapfile

" Глубина истории
set undolevels=1000

syntax on
" Цветовая схема
set t_Co=256

" monokai не идёт по умолчанию, но мы его установим чуть позже
colorscheme monokai

" Рисовать вертикальную линию для отображения границы в 120 символов — строки длинее хуже читаются
set colorcolumn=120
highlight ColorColumn ctermbg=238 guibg=#232728

" Настройка табов
set expandtab
set tabstop=4
set shiftwidth=4

" Отображать скрытые символы, табы и висящие пробелы
set list
set listchars=tab:→\ ,trail:·,nbsp:·

3. Я использую тёмную тему monokai. Её нет среди тем по умолчанию, но установить её несложно:

ls —l /usr/share/vim/vim*/colors покажет все предустановленные в системе темы

$ mkdir -p ~/.vim/colors
$ curl -o ~/.vim/colors/monokai.vim https://raw.githubusercontent.com/sickill/vim-monokai/master/colors/monokai.vim

Имя этого файла с темой нужно указать в ~/.vimrc в строке

colorscheme <monokai>

Отличная статья про апгрейд встроенного Terminal
https://medium.com/@Clovis_app/configuration-of-a-beautiful-efficient-terminal-and-prompt-on-osx-in-7-minutes-827c29391961

Краткий план действий

1. Ставим iTerm2 на замену Terminal. Они нормально сосуществуют и можно будет откатиться, если не понравится.

brew cask install iterm2

2. Ставим цветовую cхему для iTerm2 (сохраняйте именно как .itermcolors) — это набор цветов и ничего больше. На данном этапе терминал всё ещё будет выглядеть уныло.
3. Качаем шрифт с поддержкой дополнительных символов-иконок: обычный или жирный (он контрастнее) — и устанавливаем в систему. Иначе увидим не иконки, а пустые квадратики.
   Меняем размер шрифта на 12-14pt или какой удобнее.
4. Через консоль iTerm’a устанавливаем Zsh (вместо стандартного Bash) и Oh my Zsh — само ядро командной строки и оболочку с форматированием вокруг неё.

# Возможно, zsh у вас уже есть по умолчанию. Чтобы проверить, нужно ввести : 
which zsh
# Если вернёт путь, значит есть. Если нет, то ставим:
brew install zsh zsh-completions
# Устанавливаем Oh my Zsh
sh -c "$(curl -fsSL https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

5. Важно: теперь основной конфигурационный файл консоли — ~/.zshrc, а не ~/.bashrc или ~/.bash_profile.
6. Скачиваем в дефолтную директорию тему — самую маковку, которая добавит красоты в терминал

git clone https://github.com/bhilburn/powerlevel9k.git ~/.oh-my-zsh/custom/themes/powerlevel9k
# Редактируем ~/.zshrc и меняем конфиг
ZSH_THEME="powerlevel9k/powerlevel9k"

7. Перезагружаем iTerm и вуаля.

Улучшение вида и поведения терминала

1. Вид самой строки

POWERLEVEL9K_LEFT_PROMPT_ELEMENTS=(dir rbenv vcs)
POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS=(status root_indicator background_jobs history time)
POWERLEVEL9K_VCS_MODIFIED_BACKGROUND='red' # Будет менять цвет, если есть обновления в гит-репозитории

2. Я не стал делать перенос строки (POWERLEVEL9K_PROMPT_ON_NEWLINE=true), так как у меня терминал всегда на всю ширину экрана и места хватает.
3. Обязательно: iTerm → Preferences → Profiles → Keys → Load Preset… → Natural Text Editing, чтобы работала навигация через Option + стрелки и прочее.
4. Можно добавить автодополнение команд на основе истории

git clone https://github.com/zsh-users/zsh-autosuggestions $ZSH_CUSTOM/plugins/zsh-autosuggestions
vim ~/.zshrc
# Внутри файла добавляем через пробел название плагина
plugins=(… zsh-autosuggestions)

5. Включаем автозагрузку ssh-ключей при старте терминала:
   https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/ssh-agent

vim ~/.zshrc
# Внутри файла добавляем через пробел название плагина
plugins=(… ssh-agent)
# Сразу ниже включаем ssh-agent и указываем ключи через пробел — у меня их два
zstyle :omz:plugins:ssh-agent agent-forwarding on
zstyle :omz:plugins:ssh-agent identities id_rsa id_rsa2
# Эта строка у вас уже будет, главное команды выше поместить до этой строки с source
source $ZSH/oh-my-zsh.sh

6. Перезагружаем iTerm. Уже всё готово!
7. Опционально: после всех правок IDE, которые содержат встроенный терминал, могут выглядеть слегка кривовато. Нужно им помочь с определением шрифта. Например, в VS Code в настройках меняем параметры:

"terminal.integrated.fontFamily": "Meslo LG M for Powerline"
"terminal.integrated.fontSize": 12