Не отслеживать изменение прав

git config core.fileMode false

git config core.fileMode false

Исправить описание в последнем коммите

git commit --amend -m "New commit message"

git commit --amend -m "New commit message"

Анализ проекта

# Какие файлы меняются чаще всего
git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20

# Все контрибьюторы отсортированные по числу коммитов
git shortlog -sn --no-merges

# Кто активен за последние полгода
git shortlog -sn --no-merges --since="6 months ago"

# Количество коммитов помесячно
git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c

#Где скапливаются баги, отфильтровано по коммитам с ключевыми словами
git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20

# Как часто делаются revert/hotfix
git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'

# Какие файлы меняются чаще всего
git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20

# Все контрибьюторы отсортированные по числу коммитов
git shortlog -sn --no-merges

# Кто активен за последние полгода
git shortlog -sn --no-merges --since="6 months ago"

# Количество коммитов помесячно
git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c

#Где скапливаются баги, отфильтровано по коммитам с ключевыми словами
git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20

# Как часто делаются revert/hotfix
git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'

Изменить удаленный репозиторий
Проект склонирован через https, нужно изменить на ssh

# текущее состояние
git remote -v
#origin https://gitlab.com/my-username/my-project.git (fetch)
#origin https://gitlab.com/my-username/my-project.git (push)


# замена
git remote set-url origin git@gitlab.com:my-username/my-project.git

# проверка
git remote -v
# origin git@gitlab.com:my-username/my-project.git (fetch)
# origin git@gitlab.com:my-username/my-project.git (push)

# текущее состояние
git remote -v
#origin https://gitlab.com/my-username/my-project.git (fetch)
#origin https://gitlab.com/my-username/my-project.git (push)


# замена
git remote set-url origin git@gitlab.com:my-username/my-project.git

# проверка
git remote -v
# origin git@gitlab.com:my-username/my-project.git (fetch)
# origin git@gitlab.com:my-username/my-project.git (push)

Сообщение Полезные команды Git появились сначала на mcodex.

curl -fsSL https://get.docker.com | sh

# добавляем текущего пользователя в группу docker
sudo usermod -aG docker $USER
newgrp docker

curl -fsSL https://get.docker.com | sh

# добавляем текущего пользователя в группу docker
sudo usermod -aG docker $USER
newgrp docker

2. Файл docker-compose.yaml

Создаем папку, например, /docker-containers/mysql, в ней файл docker-compose.yaml

services:
  mysql:
    image: mysql:8.0
    container_name: mysql_container
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: your_root_password
      MYSQL_DATABASE: my_project_db
      MYSQL_USER: my_project_user
      MYSQL_PASSWORD: my_project_password
    volumes:
      - mysql_data:/var/lib/mysql
      - ./conf.d:/etc/mysql/conf.d
    ports:
      - "127.0.0.1:3306:3306"

volumes:
  mysql_data:

services:
  mysql:
    image: mysql:8.0
    container_name: mysql_container
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: your_root_password
      MYSQL_DATABASE: my_project_db
      MYSQL_USER: my_project_user
      MYSQL_PASSWORD: my_project_password
    volumes:
      - mysql_data:/var/lib/mysql
      - ./conf.d:/etc/mysql/conf.d
    ports:
      - "127.0.0.1:3306:3306"

volumes:
  mysql_data:

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

Пароли и имена придумываем свои, пароли долджны быть сложные, MYSQL_ROOT_PASSWORD используется при инициализации контейнера, в дальнейшем он будет нужен для подключения к MySQL от имени пользователя root, остальные данные будут нужны при подключении проекта.

3. Запускаем контейнер

cd /docker-containers/mysql
docker compose up -d

# Проверяем, что контейнер запущен
docker ps
docker logs mysql_container

# включаем автозапуск docker после перезагрузки VPS
sudo systemctl enable docker

cd /docker-containers/mysql
docker compose up -d

# Проверяем, что контейнер запущен
docker ps
docker logs mysql_container

# включаем автозапуск docker после перезагрузки VPS
sudo systemctl enable docker

При первом запуске контейнера Docker-образ MySQL сам создаёт базу и пользователя, а так-же дает пользователю все права на эту базу.

4. Импорт дампа в контейнер

На данном шаге в нашем контейнере существует пустая база данных my_project_db, в которую можно, при необходимости, загружить дамп проекта. Для этого выполняем mysql внутри контейнера.

docker exec -i mysql_container mysql -u my_project_user -p'my_project_password' my_project_db < /path/to/dump/backup-dump.sql

docker exec -i mysql_container mysql -u my_project_user -p'my_project_password' my_project_db < /path/to/dump/backup-dump.sql

Важно: это работает только при первом запуске, когда volume ещё пустой. Если контейнер уже запускался и данные есть — переменные игнорируются, база уже существует.

Проверям, что импорт прошел успешно.

docker exec -it mysql_container mysql -u my_project_user -p'my_project_password' my_project_db -e "SHOW TABLES;"

docker exec -it mysql_container mysql -u my_project_user -p'my_project_password' my_project_db -e "SHOW TABLES;"

В выводе должен быть список таблиц в базе данных my_project_db

5. Подключаем проект

Теперь нужно подключить проект к контейнеру с базой данных. Проекты могут использовать разные фреймворки и CMS.

Вариант А. Проект на WordPress.

Переходим в папку проекта, открываем файл wp-config.php, меняем значения констант.

define( 'DB_NAME', 'my_project_db' );
define( 'DB_USER', 'my_project_user' );
define( 'DB_PASSWORD', 'my_project_password' );
define( 'DB_HOST', '127.0.0.1:3306' );

define( 'DB_NAME', 'my_project_db' );
define( 'DB_USER', 'my_project_user' );
define( 'DB_PASSWORD', 'my_project_password' );
define( 'DB_HOST', '127.0.0.1:3306' );

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

6. Добавление еще одной базы данных

Сейчас в контейнере создана только одна база данных для проекта my_project. Предположим, на этом же VPS расположен еще один проект, my_project2. Создадим в этом же контейнере еще одну БД для этого проекта. Для этого заходим в контейнер как пользователь root (пароль берем из MYSQL_ROOT_PASSWORD файла docker-compose.yaml ) и создаем нового пользователя и базу данных.

# Зайди в контейнер
docker exec -it mysql_container mysql -u root -p

# Внутри MySQL создай всё для второго сайта
CREATE DATABASE my_project2_db;
CREATE USER 'my_project2_user'@'%' IDENTIFIED BY 'my_project2_password';
GRANT ALL PRIVILEGES ON my_project2_db.* TO 'my_project2_user'@'%';
QUIT;

# Зайди в контейнер
docker exec -it mysql_container mysql -u root -p

# Внутри MySQL создай всё для второго сайта
CREATE DATABASE my_project2_db;
CREATE USER 'my_project2_user'@'%' IDENTIFIED BY 'my_project2_password';
GRANT ALL PRIVILEGES ON my_project2_db.* TO 'my_project2_user'@'%';
QUIT;

Подключение во второй проект аналогично п5.

7. Хранение данных

Разбираемся, где лежат файлы MySQL на хост-машине.
В docker-compose.yaml указан именованный том mysql_data. По сути это папка на хосте, в которой лежат файлы MySQL. Так же указано, что на нее маппируется папка /var/lib/mysql в контейнере (стандартная папка с данными MySQL). Что бы узнать точное имя тома (папки) можно выполнить команду:

docker volume ls

# Вывод
# DRIVER    VOLUME NAME
# local     mysql-docker_mysql_data
# local     mysql_mysql_data

docker volume ls

# Вывод
# DRIVER    VOLUME NAME
# local     mysql-docker_mysql_data
# local     mysql_mysql_data

Видно, что точное имя тома mysql_mysql_data, так как к имени, указанному в опции volume добавляется имя папки, в которой лежит docker-compose.yaml, которое считается префиксом проекта.

Проверяем, где находится данный том

docker volume inspect mysql_mysql_data

# Вывод
# ....
# "Mountpoint": "/var/lib/docker/volumes/mysql_mysql_data/_data",
# "Name": "mysql_mysql_data",
# ....

docker volume inspect mysql_mysql_data

# Вывод
# ....
# "Mountpoint": "/var/lib/docker/volumes/mysql_mysql_data/_data",
# "Name": "mysql_mysql_data",
# ....

Mountpoint — это и есть путь к папке тома на хост-машине.
Том не зависит от контейнера, поэтому при остановке, перезапуске, удалении контейнера данные в базе данных будут сохранены.

Сделать дамп одной базы данных

docker exec mysql_container mysqldump \
  -u my_project_user -p'my_project_password' \
  my_project_db > my_project_db.sql

docker exec mysql_container mysqldump \
  -u my_project_user -p'my_project_password' \
  my_project_db > my_project_db.sql

Сделать дамп всех баз данных

docker exec mysql_container mysqldump \
  -u root -p'your_root_password' \
  --all-databases > backup_all.sql

docker exec mysql_container mysqldump \
  -u root -p'your_root_password' \
  --all-databases > backup_all.sql

Восстановление из дампа

docker exec -i mysql_container mysql \
  -u my_project_user -p'my_project_password' \
  my_project_db < backup.sql

docker exec -i mysql_container mysql \
  -u my_project_user -p'my_project_password' \
  my_project_db < backup.sql

8. Полезные команды docker

Напоминание:
1. mysql_container — это не зарезервированное слово, это имя контейнера, заданное в файле docker-compose.yaml (см. п2), может быть любым.
2. команда ‘docker’ может выполнятся из любой папки.
3. команда ‘docker compose’ выполняется из папки, в которой находится файл docker-compose.yaml (или указывается путь к файлу через флаг -f)

Сообщение Использование MySQL в контейнере Docker появились сначала на mcodex.

• Описание задачи и требования к проекту
• Начальная настройка проекта
• Пользователи для деплоя
• SSH-ключи
• Переменные Gitlab
• Структура проекта для CICD
• Переключение Nginx на новый проект
• Первый деплой через CICD
• Откат

Описание задачи и требования к проекту

Проект разрабатыватся на локальной машине, есть 2 сервера, dev и prodcution.
Стэк одинаковый: VPS Ubuntu/Nginx/PHP/MySQL/Laravel/Supervisor

Шаги в инструкции выполняются на обеих серверах. В результате получаем 2 развернутых версии проекта:
на dev-сервере (ветка develop) и production (ветка main).

После применения инструкции все дальнейшие загрузки обновлений происходят без ручного вмешательства на серверах, на dev-сервере — после пуша в ветку develop, на production — после пуша (или PR) в main и клика на кнопке деплоя (опциональный предохранитель).

Перед внедрением CICD, необходимо проверить следующие пункты:

1. На серверах есть полномочия sudo
2. В проекте есть тесты
3. В проекте есть публично доступный роут GET /health/ready, возвращает код 200.
4. Перед пушем в gitlab прогоняем тесты, линтер, pint.

Шаг 1. Начальная настройка проекта

Разворачиваем проекты на серверах из репозитория Gitlab вручную, без CICD, настраиваем Nginx, подключаем СУБД и т.д. Проверяем, что все работает.
Предположим, проект развернут в папке /var/www/my-project.com/classic-deploy

Сразу решаем, в какой папке будет расположен проект, разворачиваемый через CICD.
Допустим, он будет в папке /var/www/my-project.com/cicd-deploy

Шаг 2. Создаем пользователя для деплоя

2.1 На обеих серверах добавляем пользователя deployer. Через него Gitlab будет делать деплой.

sudo adduser deployer

sudo adduser deployer

2.2 Добавляем пользователя deployer в группу www-data

sudo usermod -aG www-data deployer

sudo usermod -aG www-data deployer

Проверяем, что добавлен в группу

groups deployer

groups deployer

в списке должна быть www-data

2.3 Добавляем возможность запуска от имени deployer определенных команд без пароля.
Для этого создаем файл конфига:

sudo visudo -f /etc/sudoers.d/deploy

sudo visudo -f /etc/sudoers.d/deploy

Добавляем в него строку (версию PHP при необходимости изменить):

deployer ALL=(ALL) NOPASSWD: /usr/bin/supervisorctl, /usr/bin/systemctl reload php8.5-fpm

deployer ALL=(ALL) NOPASSWD: /usr/bin/supervisorctl, /usr/bin/systemctl reload php8.5-fpm

Перед добавлвением можно проверить, где находятся файлы

which supervisorctl
which systemctl

which supervisorctl
which systemctl

Шаг 3. Настраиваем SSH-ключи

Логинимся на сервер как пользователь deployer

ssh deployer@ip-address-here

ssh deployer@ip-address-here

Создаем новый ключ, без ключевой фразы, для дев-сервера используем префикс dev

ssh-keygen -t ed25519 -C "gitlab-deploy-prod"

ssh-keygen -t ed25519 -C "gitlab-deploy-prod"

Появляется папка /home/deployer/.ssh, в ней файлы ключа id_ed25519.pub и id_ed25519.
Имена файлов ключей лучше использовать дефолтные, иначе може возникнуть ошибка при подключении к Gitlab.

Добавляем публичный ключ в authorized_keys

cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys

cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys

Содержимое файла публичного ключа добавляем в ключи в репозитории проекта на Gitlab
Settings->Reposirory->Deploy keys->Add new key

В названии ключа указываем сервер и пользователя, что бы не путаться, например, «Production deployer»

Секретный ключ кодируем в base64

base64 -w 0 ~/.ssh/id_ed25519

base64 -w 0 ~/.ssh/id_ed25519

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

Проверяем, что ключ работает. Для этого в произвольной папке клонируем репозиторий

mkdir ~/test
cd ~/test
git clone git@gitlab.com:your-project.git

mkdir ~/test
cd ~/test
git clone git@gitlab.com:your-project.git

Если клонирование прошло успешно, тестовую папку можно удалить.

Шаг 4. Задаем переменные Gitlab

В Gitlab, в папке проекта открываем Settings->CICD->Variables
Создаем переменные:
PROD_HOST — IP адрес, например, 123.1.123.12
PROD_BASE — путь к папке cicd-проекта, /var/www/my-project.com/cicd-deploy
PROD_APP_URL — публичный URL проекта, для запуска health check, например, https://my-project.com.
PROD_USER — deployer
PROD_SSH_PRIVATE_KEY_B64 — приватный ключ в формате base64 из предыдущего шага
Тип переменной — variable (default), visibility: visible, protect variable — выключено
Для дев-севера аналогично, но с префиксом DEV_

В результате в репозитории есть набор переменных

Результат на данном этапе:
Проект работает по прежнему из папки classic-deploy, на сервере добавлен пользователь deployer.

Шаг 5. Создаем структуру проекта для CICD

Допустим, проект, развернутый через CICD будет расположен в папке /var/www/my-project.com/cicd-deploy

В этом случае структура downtime-zero проекта будет следующей

/var/www/my-porject.com/cicd-deploy/
  ├── current -> releases/20260501-1430-abc1234 ← симлинк на активный релиз
  ├── releases/
  │ ├── 20260430-1731-2b5cc17/
  │ ├── 20260501-0900-69025b4/
  │ └── 20260501-1430-abc1234/ ← текущий
  └── shared/
    ├── .env
    └── storage/

/var/www/my-porject.com/cicd-deploy/
  ├── current -> releases/20260501-1430-abc1234 ← симлинк на активный релиз
  ├── releases/
  │ ├── 20260430-1731-2b5cc17/
  │ ├── 20260501-0900-69025b4/
  │ └── 20260501-1430-abc1234/ ← текущий
  └── shared/
    ├── .env
    └── storage/

5.1 Делаем первый деплой вручную.

Логинимся под root, создаем папку ~/deploy, в нее кладем файл first_deploy.sh

Заменить:
BASE — путь к новой папке проекта
OLD_PATH — текущий проект
REPO — репозиторий Gitlab

#!/usr/bin/env bash
umask 0002
set -euo pipefail

BASE=/var/www/my-project.com/cicd-deploy
OLD_PATH=/var/www/my-porject.com/classic-deploy
SHARED=$BASE/shared
TS=$(date +%Y%m%d-%H%M)
REL=$BASE/releases/${TS}-manual
REPO=git@gitlab.com:your-project-repo.git

mkdir -p $BASE/releases
mkdir -p $BASE/shared/storage/{app/public,framework/cache/data,framework/sessions,framework/testing,framework/views,logs}
sudo chown -R deployer:www-data $BASE
sudo find $BASE -type d -exec chmod 2775 {} \;
sudo find $BASE -type f -exec chmod 0664 {} \;

cp -a $OLD_PATH/.env $BASE/shared/.env
cp -a $OLD_PATH/storage/. $BASE/shared/storage/
sudo chown -R deployer:www-data $BASE/shared
sudo find $BASE/shared -type d -exec chmod 2775 {} \;
sudo find $BASE/shared -type f -exec chmod 0664 {} \;
sudo chmod 0640 $BASE/shared/.env

sudo -u deployer git clone --depth 1 --branch develop "$REPO" "$REL"

sudo -u deployer ln -sfn "$SHARED/.env" "$REL/.env"
sudo -u deployer rm -rf "$REL/storage"
sudo -u deployer ln -sfn "$SHARED/storage" "$REL/storage"

# на production-сервере добавить опцию --no-dev
sudo -u deployer bash -c "cd '$REL' && composer install --optimize-autoloader --no-interaction"
sudo -u deployer php "$REL/artisan" storage:link
sudo -u deployer php "$REL/artisan" config:cache
sudo -u deployer php "$REL/artisan" route:cache
sudo -u deployer php "$REL/artisan" view:cache
sudo -u deployer php "$REL/artisan" event:cache
sudo -u deployer php "$REL/artisan" migrate --force

sudo rm -rf "$BASE/current.new"
sudo -u deployer ln -sfn "$REL" "$BASE/current.new"
sudo -u deployer mv -Tf "$BASE/current.new" "$BASE/current"

#!/usr/bin/env bash
umask 0002
set -euo pipefail

BASE=/var/www/my-project.com/cicd-deploy
OLD_PATH=/var/www/my-porject.com/classic-deploy
SHARED=$BASE/shared
TS=$(date +%Y%m%d-%H%M)
REL=$BASE/releases/${TS}-manual
REPO=git@gitlab.com:your-project-repo.git

mkdir -p $BASE/releases
mkdir -p $BASE/shared/storage/{app/public,framework/cache/data,framework/sessions,framework/testing,framework/views,logs}
sudo chown -R deployer:www-data $BASE
sudo find $BASE -type d -exec chmod 2775 {} \;
sudo find $BASE -type f -exec chmod 0664 {} \;

cp -a $OLD_PATH/.env $BASE/shared/.env
cp -a $OLD_PATH/storage/. $BASE/shared/storage/
sudo chown -R deployer:www-data $BASE/shared
sudo find $BASE/shared -type d -exec chmod 2775 {} \;
sudo find $BASE/shared -type f -exec chmod 0664 {} \;
sudo chmod 0640 $BASE/shared/.env

sudo -u deployer git clone --depth 1 --branch develop "$REPO" "$REL"

sudo -u deployer ln -sfn "$SHARED/.env" "$REL/.env"
sudo -u deployer rm -rf "$REL/storage"
sudo -u deployer ln -sfn "$SHARED/storage" "$REL/storage"

# на production-сервере добавить опцию --no-dev
sudo -u deployer bash -c "cd '$REL' && composer install --optimize-autoloader --no-interaction"
sudo -u deployer php "$REL/artisan" storage:link
sudo -u deployer php "$REL/artisan" config:cache
sudo -u deployer php "$REL/artisan" route:cache
sudo -u deployer php "$REL/artisan" view:cache
sudo -u deployer php "$REL/artisan" event:cache
sudo -u deployer php "$REL/artisan" migrate --force

sudo rm -rf "$BASE/current.new"
sudo -u deployer ln -sfn "$REL" "$BASE/current.new"
sudo -u deployer mv -Tf "$BASE/current.new" "$BASE/current"

Что делает скрипт:

• Создает структуру проекта
• Копирует shared-файлы из текущего проекта
• Создает первый релиз с префиксом manual
• Устанавливает права

Перед запуском проверяем текущую версию CLI PHP, она должна соответствовать требованиям пакетов в composer.lock, иначе возникнет ошибка при установке пакетов.

php -v

php -v

При необходимости, переключаем на нужную версию:

sudo update-alternatives --set php /usr/bin/php8.5

sudo update-alternatives --set php /usr/bin/php8.5

Запускаем скрипт

cd ~/deploy
bash first_deploy.sh

cd ~/deploy
bash first_deploy.sh

В результате в папке var/www/my-project.com/cicd-deploy создается структура ciccd-проекта, но он пока не работает, так как Nginx отправляет запросы на старый проект.

Шаг 6. Переключаем Nginx на новый проект

6.1 В файле конфигурации Nginx меняем путь для root на
/var/www/my-project.com/cicd-deploy/current/public

Перезагружаем Nginx

nginx -t
systemctl reload nginx 

nginx -t
systemctl reload nginx 

6.2 Меняем конфигурацию supervisor

nano /etc/supervisor/conf.d/horizon.conf

## меняем пути  
command=php /var/www/my-project.com/cicd-deploy/current/artisan horizon
directory=/var/www/my-project.com/cicd-deploy/current
stdout_logfile=/var/www/my-project.com/cicd-deploy/shared/storage/logs/horizon.log

supervisorctl reread && supervisorctl update

nano /etc/supervisor/conf.d/horizon.conf

## меняем пути  
command=php /var/www/my-project.com/cicd-deploy/current/artisan horizon
directory=/var/www/my-project.com/cicd-deploy/current
stdout_logfile=/var/www/my-project.com/cicd-deploy/shared/storage/logs/horizon.log

supervisorctl reread && supervisorctl update

6.3 Важно: не забыть проверить и заменить пути в заданиях cron, пути (если есть) в файле .env, в файле конфигураций.

Теперь проект работает из новой папки, релиз -manual.

Проверяем, что все работает, адрес /health/ready возвращает JSON с 200

Шаг 7. Делаем первый деплой через Gitlab CICD Pipeline.

7.1 На локальном сервере добавляем в корневую проекта файл пайплайна .gitlab-ci.yaml

stages:
  - test
  - deploy

# ──────────────── ТЕСТЫ ────────────────
test:
  stage: test
  image: php:8.5-cli
  cache:
    key:
      files: [composer.lock]
    paths: [vendor/]
  variables:
    DB_CONNECTION: sqlite
    DB_DATABASE: ":memory:"
  before_script:
    - apt-get update -qq && apt-get install -y -qq git unzip libicu-dev libzip-dev libsqlite3-dev
    - docker-php-ext-install intl pcntl zip pdo_sqlite
    - curl -sS https://getcomposer.org/installer | php
    - php composer.phar install --prefer-dist --no-ansi --no-progress
    - cp .env.example .env
    - php artisan key:generate
  script:
    - php artisan test --compact
  rules:
    - if: $CI_COMMIT_BRANCH == "main" # запускаем тест при пуше в main
    - if: $CI_COMMIT_BRANCH == "develop" # запускаем тест при пуше в develop
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" # запускаем тест при PR
# тесты не запускаются при пуше в feature-ветки

# ──────────────── ДЕПЛОЙ НА DEV ────────────────
deploy:dev:
  stage: deploy
  needs: [test]
  image: alpine:latest
  variables:
    KEEP_RELEASES: "5"
    HEALTH_URL: "${DEV_APP_URL}/health/ready"
  script:
    - apk add --no-cache openssh-client curl
    - mkdir -p ~/.ssh && chmod 700 ~/.ssh
    - echo "$DEV_SSH_PRIVATE_KEY_B64" | base64 -d > ~/.ssh/id_deploy
    - chmod 600 ~/.ssh/id_deploy
    - ssh-keyscan -H "$DEV_HOST" >> ~/.ssh/known_hosts
    - |
      ssh -i ~/.ssh/id_deploy "$DEV_USER@$DEV_HOST" \
        "BASE='$DEV_BASE' SHA='$CI_COMMIT_SHORT_SHA' FULL_SHA='$CI_COMMIT_SHA' REPO='$CI_REPOSITORY_URL' KEEP_RELEASES='$KEEP_RELEASES' bash -se" <<'EOSSH'
        set -euo pipefail
        umask 0002
        TS=$(date +%Y%m%d-%H%M)
        REL="$BASE/releases/${TS}-${SHA}"
        SHARED="$BASE/shared"

        git config --global --add safe.directory "$REL"

        # 1. Клонируем релиз (shallow) от develop
        git clone --depth 1 --branch develop "$REPO" "$REL"
        cd "$REL"
        echo "$FULL_SHA" > RELEASE

        # 2. Гарантируем структуру shared (на случай первого деплоя/чистого shared)
        mkdir -p "$SHARED/storage/app/public" \
                 "$SHARED/storage/framework/cache/data" \
                 "$SHARED/storage/framework/sessions" \
                 "$SHARED/storage/framework/testing" \
                 "$SHARED/storage/framework/views" \
                 "$SHARED/storage/logs"

        # 3. Линкуем shared
        ln -sfn "$SHARED/.env" .env
        rm -rf storage && ln -sfn "$SHARED/storage" storage

        # 3. Установка зависимостей (на новом релизе, не трогая current)
        composer install --optimize-autoloader --no-interaction --no-progress

        # 4. Symlink public/storage -> storage/app/public
        php artisan storage:link

        # 5. Кеши конфигов/роутов/вью — в новом релизе
        php artisan config:cache
        php artisan route:cache
        php artisan view:cache
        php artisan event:cache

        # 5. Миграции (один раз на релиз; делаем ДО переключения)
        php artisan migrate --force

        # 6. Атомарное переключение symlink current
        ln -sfn "$REL" "$BASE/current.new"
        mv -Tf "$BASE/current.new" "$BASE/current"

        # 7. Перезапуск Horizon (graceful)
        sudo supervisorctl signal SIGTERM horizon:* || php artisan horizon:terminate

        # 8. Reload php-fpm для сброса opcache (graceful, без downtime)
        sudo systemctl reload php8.5-fpm

        # 9. Чистим старые релизы
        cd "$BASE/releases" && ls -1t | tail -n +$((KEEP_RELEASES+1)) | xargs -r rm -rf
      EOSSH
    # 10. Health check после деплоя
    - |
      echo "Health check: $HEALTH_URL"
      for i in 1 2 3 4 5; do
        code=$(curl -s -o /tmp/health.out -w "%{http_code}" "$HEALTH_URL" || echo "000")
        echo "attempt $i: HTTP $code"
        if [ "$code" = "200" ]; then
          cat /tmp/health.out; echo
          exit 0
        fi
        sleep 3
      done
      echo "Health check failed"; cat /tmp/health.out 2>/dev/null || true
      exit 1
  rules:
    - if: $CI_COMMIT_BRANCH == "develop"

# ──────────────── ДЕПЛОЙ НА PROD ────────────────
deploy:prod:
  stage: deploy
  when: manual
  needs: [test]
  image: alpine:latest
  variables:
    KEEP_RELEASES: "5"
    HEALTH_URL: "${PROD_APP_URL}/health/ready"
  script:
    - apk add --no-cache openssh-client curl
    - mkdir -p ~/.ssh && chmod 700 ~/.ssh
    - echo "$PROD_SSH_PRIVATE_KEY_B64" | base64 -d > ~/.ssh/id_deploy
    - chmod 600 ~/.ssh/id_deploy
    - ssh-keyscan -H "$PROD_HOST" >> ~/.ssh/known_hosts
    - |
      ssh -i ~/.ssh/id_deploy "$PROD_USER@$PROD_HOST" \
        "BASE='$PROD_BASE' SHA='$CI_COMMIT_SHORT_SHA' FULL_SHA='$CI_COMMIT_SHA' REPO='$CI_REPOSITORY_URL' KEEP_RELEASES='$KEEP_RELEASES' bash -se" <<'EOSSH'
        set -euo pipefail
        umask 0002
        TS=$(date +%Y%m%d-%H%M)
        REL="$BASE/releases/${TS}-${SHA}"
        SHARED="$BASE/shared"

        git config --global --add safe.directory "$REL"

        # 1. Клонируем релиз (shallow) от main
        git clone --depth 1 --branch main "$REPO" "$REL"
        cd "$REL"
        echo "$FULL_SHA" > RELEASE

        # 2. Гарантируем структуру shared (на случай первого деплоя/чистого shared)
        mkdir -p "$SHARED/storage/app/public" \
                 "$SHARED/storage/framework/cache/data" \
                 "$SHARED/storage/framework/sessions" \
                 "$SHARED/storage/framework/testing" \
                 "$SHARED/storage/framework/views" \
                 "$SHARED/storage/logs"

        # 3. Линкуем shared
        ln -sfn "$SHARED/.env" .env
        rm -rf storage && ln -sfn "$SHARED/storage" storage

        # 3. Установка зависимостей (на новом релизе, не трогая current)
        composer install --no-dev --optimize-autoloader --no-interaction --no-progress

        # 4. Symlink public/storage -> storage/app/public
        php artisan storage:link

        # 5. Кеши конфигов/роутов/вью — в новом релизе
        php artisan config:cache
        php artisan route:cache
        php artisan view:cache
        php artisan event:cache

        # 5. Миграции (один раз на релиз; делаем ДО переключения)
        php artisan migrate --force

        # 6. Атомарное переключение symlink current
        ln -sfn "$REL" "$BASE/current.new"
        mv -Tf "$BASE/current.new" "$BASE/current"

        # 7. Перезапуск Horizon (graceful)
        sudo supervisorctl signal SIGTERM horizon:* || php artisan horizon:terminate

        # 8. Reload php-fpm для сброса opcache (graceful, без downtime)
        sudo systemctl reload php8.5-fpm

        # 9. Чистим старые релизы
        cd "$BASE/releases" && ls -1t | tail -n +$((KEEP_RELEASES+1)) | xargs -r rm -rf
      EOSSH
    # 10. Health check после деплоя
    - |
      echo "Health check: $HEALTH_URL"
      for i in 1 2 3 4 5; do
        code=$(curl -s -o /tmp/health.out -w "%{http_code}" "$HEALTH_URL" || echo "000")
        echo "attempt $i: HTTP $code"
        if [ "$code" = "200" ]; then
          cat /tmp/health.out; echo
          exit 0
        fi
        sleep 3
      done
      echo "Health check failed"; cat /tmp/health.out 2>/dev/null || true
      exit 1
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

stages:
  - test
  - deploy

# ──────────────── ТЕСТЫ ────────────────
test:
  stage: test
  image: php:8.5-cli
  cache:
    key:
      files: [composer.lock]
    paths: [vendor/]
  variables:
    DB_CONNECTION: sqlite
    DB_DATABASE: ":memory:"
  before_script:
    - apt-get update -qq && apt-get install -y -qq git unzip libicu-dev libzip-dev libsqlite3-dev
    - docker-php-ext-install intl pcntl zip pdo_sqlite
    - curl -sS https://getcomposer.org/installer | php
    - php composer.phar install --prefer-dist --no-ansi --no-progress
    - cp .env.example .env
    - php artisan key:generate
  script:
    - php artisan test --compact
  rules:
    - if: $CI_COMMIT_BRANCH == "main" # запускаем тест при пуше в main
    - if: $CI_COMMIT_BRANCH == "develop" # запускаем тест при пуше в develop
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" # запускаем тест при PR
# тесты не запускаются при пуше в feature-ветки

# ──────────────── ДЕПЛОЙ НА DEV ────────────────
deploy:dev:
  stage: deploy
  needs: [test]
  image: alpine:latest
  variables:
    KEEP_RELEASES: "5"
    HEALTH_URL: "${DEV_APP_URL}/health/ready"
  script:
    - apk add --no-cache openssh-client curl
    - mkdir -p ~/.ssh && chmod 700 ~/.ssh
    - echo "$DEV_SSH_PRIVATE_KEY_B64" | base64 -d > ~/.ssh/id_deploy
    - chmod 600 ~/.ssh/id_deploy
    - ssh-keyscan -H "$DEV_HOST" >> ~/.ssh/known_hosts
    - |
      ssh -i ~/.ssh/id_deploy "$DEV_USER@$DEV_HOST" \
        "BASE='$DEV_BASE' SHA='$CI_COMMIT_SHORT_SHA' FULL_SHA='$CI_COMMIT_SHA' REPO='$CI_REPOSITORY_URL' KEEP_RELEASES='$KEEP_RELEASES' bash -se" <<'EOSSH'
        set -euo pipefail
        umask 0002
        TS=$(date +%Y%m%d-%H%M)
        REL="$BASE/releases/${TS}-${SHA}"
        SHARED="$BASE/shared"

        git config --global --add safe.directory "$REL"

        # 1. Клонируем релиз (shallow) от develop
        git clone --depth 1 --branch develop "$REPO" "$REL"
        cd "$REL"
        echo "$FULL_SHA" > RELEASE

        # 2. Гарантируем структуру shared (на случай первого деплоя/чистого shared)
        mkdir -p "$SHARED/storage/app/public" \
                 "$SHARED/storage/framework/cache/data" \
                 "$SHARED/storage/framework/sessions" \
                 "$SHARED/storage/framework/testing" \
                 "$SHARED/storage/framework/views" \
                 "$SHARED/storage/logs"

        # 3. Линкуем shared
        ln -sfn "$SHARED/.env" .env
        rm -rf storage && ln -sfn "$SHARED/storage" storage

        # 3. Установка зависимостей (на новом релизе, не трогая current)
        composer install --optimize-autoloader --no-interaction --no-progress

        # 4. Symlink public/storage -> storage/app/public
        php artisan storage:link

        # 5. Кеши конфигов/роутов/вью — в новом релизе
        php artisan config:cache
        php artisan route:cache
        php artisan view:cache
        php artisan event:cache

        # 5. Миграции (один раз на релиз; делаем ДО переключения)
        php artisan migrate --force

        # 6. Атомарное переключение symlink current
        ln -sfn "$REL" "$BASE/current.new"
        mv -Tf "$BASE/current.new" "$BASE/current"

        # 7. Перезапуск Horizon (graceful)
        sudo supervisorctl signal SIGTERM horizon:* || php artisan horizon:terminate

        # 8. Reload php-fpm для сброса opcache (graceful, без downtime)
        sudo systemctl reload php8.5-fpm

        # 9. Чистим старые релизы
        cd "$BASE/releases" && ls -1t | tail -n +$((KEEP_RELEASES+1)) | xargs -r rm -rf
      EOSSH
    # 10. Health check после деплоя
    - |
      echo "Health check: $HEALTH_URL"
      for i in 1 2 3 4 5; do
        code=$(curl -s -o /tmp/health.out -w "%{http_code}" "$HEALTH_URL" || echo "000")
        echo "attempt $i: HTTP $code"
        if [ "$code" = "200" ]; then
          cat /tmp/health.out; echo
          exit 0
        fi
        sleep 3
      done
      echo "Health check failed"; cat /tmp/health.out 2>/dev/null || true
      exit 1
  rules:
    - if: $CI_COMMIT_BRANCH == "develop"

# ──────────────── ДЕПЛОЙ НА PROD ────────────────
deploy:prod:
  stage: deploy
  when: manual
  needs: [test]
  image: alpine:latest
  variables:
    KEEP_RELEASES: "5"
    HEALTH_URL: "${PROD_APP_URL}/health/ready"
  script:
    - apk add --no-cache openssh-client curl
    - mkdir -p ~/.ssh && chmod 700 ~/.ssh
    - echo "$PROD_SSH_PRIVATE_KEY_B64" | base64 -d > ~/.ssh/id_deploy
    - chmod 600 ~/.ssh/id_deploy
    - ssh-keyscan -H "$PROD_HOST" >> ~/.ssh/known_hosts
    - |
      ssh -i ~/.ssh/id_deploy "$PROD_USER@$PROD_HOST" \
        "BASE='$PROD_BASE' SHA='$CI_COMMIT_SHORT_SHA' FULL_SHA='$CI_COMMIT_SHA' REPO='$CI_REPOSITORY_URL' KEEP_RELEASES='$KEEP_RELEASES' bash -se" <<'EOSSH'
        set -euo pipefail
        umask 0002
        TS=$(date +%Y%m%d-%H%M)
        REL="$BASE/releases/${TS}-${SHA}"
        SHARED="$BASE/shared"

        git config --global --add safe.directory "$REL"

        # 1. Клонируем релиз (shallow) от main
        git clone --depth 1 --branch main "$REPO" "$REL"
        cd "$REL"
        echo "$FULL_SHA" > RELEASE

        # 2. Гарантируем структуру shared (на случай первого деплоя/чистого shared)
        mkdir -p "$SHARED/storage/app/public" \
                 "$SHARED/storage/framework/cache/data" \
                 "$SHARED/storage/framework/sessions" \
                 "$SHARED/storage/framework/testing" \
                 "$SHARED/storage/framework/views" \
                 "$SHARED/storage/logs"

        # 3. Линкуем shared
        ln -sfn "$SHARED/.env" .env
        rm -rf storage && ln -sfn "$SHARED/storage" storage

        # 3. Установка зависимостей (на новом релизе, не трогая current)
        composer install --no-dev --optimize-autoloader --no-interaction --no-progress

        # 4. Symlink public/storage -> storage/app/public
        php artisan storage:link

        # 5. Кеши конфигов/роутов/вью — в новом релизе
        php artisan config:cache
        php artisan route:cache
        php artisan view:cache
        php artisan event:cache

        # 5. Миграции (один раз на релиз; делаем ДО переключения)
        php artisan migrate --force

        # 6. Атомарное переключение symlink current
        ln -sfn "$REL" "$BASE/current.new"
        mv -Tf "$BASE/current.new" "$BASE/current"

        # 7. Перезапуск Horizon (graceful)
        sudo supervisorctl signal SIGTERM horizon:* || php artisan horizon:terminate

        # 8. Reload php-fpm для сброса opcache (graceful, без downtime)
        sudo systemctl reload php8.5-fpm

        # 9. Чистим старые релизы
        cd "$BASE/releases" && ls -1t | tail -n +$((KEEP_RELEASES+1)) | xargs -r rm -rf
      EOSSH
    # 10. Health check после деплоя
    - |
      echo "Health check: $HEALTH_URL"
      for i in 1 2 3 4 5; do
        code=$(curl -s -o /tmp/health.out -w "%{http_code}" "$HEALTH_URL" || echo "000")
        echo "attempt $i: HTTP $code"
        if [ "$code" = "200" ]; then
          cat /tmp/health.out; echo
          exit 0
        fi
        sleep 3
      done
      echo "Health check failed"; cat /tmp/health.out 2>/dev/null || true
      exit 1
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

Необходимо убедится, что адрес /health/ready доступен, возвращает JSON с 200.

7.2 Тестируем пайплайн

Сначала проверяем дев-сервер.

На локальной машине в ветке develop делаем правки, коммитим и пушим в репозиторий Gitlab, в удаленную ветку develop.
Gitlab запускает пайплайн для develop, посмотреть можно в резделе Project->Build->Pipelines.
Сначала выполняется задача с тестами, затем задача с деплоем на дев-сервер. Если все успешно — появляется зеленая метка Passed. Проверяем на дев-сервере, что обновление загрузилось.

Если какая-либо задача в пайплайне завершилась с ошибкой — появится метка Failed, нажав на нее можно увидеть какая именно задача зафейлилась, нажав на задачу можно посмотреть лог, в чем именно ошибка. Там же можно перезапустить задачу, если исправление ошибки не требует нового коммита.

Теперь проверяем деплой на production.

Текущее состояние production перед тестом:

• две папки проектов: /classic-deploy и /cicd-deploy
• проект работает из папки /cicd-deploy, current указывает на релиз ‘-manual’

Для запуска пайплайна в удаленную ветку main необходимо загрузить коммит слияния с веткой develop.

Есть 2 варианта, можно выбрать любой:
a. Смерджить в локальном репозитории develop в main и затем запушить main в удаленный.
b. Смерджить ветку develop в main в самом Gitlab.

Выбираем вариант b.
Переходим Project->Code->Merge request, нажимаем Create merge request
Появляется надпись Ready to merge, перед слиянием запускается задача пайплайна с тестом.

Если тесты проходят, ветки сливаются, ‘Ready to merge’ меняется на ‘mered by … ‘ и запускается заново пайплайн.
Снова проходит задача с тестом, а задача деплоя на прод, в отличие от задачи деплоя на dev-сервер, не запускается, а пропускается, становится статус ‘passed’. Это защита от случайного пуша в main, в пайплайне в задаче деплоя на прод стоит опция when:manual, то есть нужен ручной запуск. Заходим в задачу и нажимаем кнопку Run.

После завершения задач на проде появляется новый релиз, current переключен на него.

Проверяем, что проект работает, после этого папку со старым вариантом деплоя (classic-deploy) можно удалить.

Шаг 8. Проверяем откат

Что бы вернутся на предыдущий релиз, необходимо переключить ссылку current на папку предыдущего релиза.

Для этого можно использовать следующий скрипт,

#!/bin/bash
set -euo pipefail
BASE=//var/www/my-project.com/cicd-deploy

cd "$BASE/releases"

PREV=$(ls -1t | sed -n '2p')   # второй сверху = предыдущий
[ -z "$PREV" ] && { echo "No previous release"; exit 1; }

echo "Rolling back to: $PREV"
ln -sfn "$BASE/releases/$PREV" "$BASE/current.new"
mv -Tf "$BASE/current.new" "$BASE/current"

sudo supervisorctl signal SIGTERM horizon:* || true
sudo systemctl reload php8.5-fpm

echo "Done."

#!/bin/bash
set -euo pipefail
BASE=//var/www/my-project.com/cicd-deploy

cd "$BASE/releases"

PREV=$(ls -1t | sed -n '2p')   # второй сверху = предыдущий
[ -z "$PREV" ] && { echo "No previous release"; exit 1; }

echo "Rolling back to: $PREV"
ln -sfn "$BASE/releases/$PREV" "$BASE/current.new"
mv -Tf "$BASE/current.new" "$BASE/current"

sudo supervisorctl signal SIGTERM horizon:* || true
sudo systemctl reload php8.5-fpm

echo "Done."

Файл скрипта rollback.sh можно положить в папку ~/home/deployer/deploy_scripts/my-project/ и запускать командой

bash rollback.sh

bash rollback.sh

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

Сообщение Zero-downtime деплой через CICD Gitlab появились сначала на mcodex.

• фреймворки (например Laravel, Symfony, Yii)
• СMS (например, WordPress, Drupal, Joomla)
• веб-сервисы SaaS
• API для фронтенда, мобильных приложений
• динамические веб-страницы,
• консольные CLI-утилиты (например, Deployer, Composer)

Основные особенности языка:

• язык является интерпретируемым, но начиная с версии 8.0 у него появился JIT-компилятор
• выполнение на сервере, хотя, к слову, технология WebAssembly позволяет выполнять код PHP в браузере, но этот подход имеет узкую специализацию, в основном для
  создания онлайн-песочниц
• нет нативной реализации EventLoop из коробки для реализации асинхронности, но решается через сторонние библиотеки, например, ReactPHP, Swoole
• нет многопоточности из коробки, как у Java или Golang, решается через расширения, например, parallel
• в традиционном использовании 1 http-запрос = 1 процесс, решается через менеджер процессов PHP-FPM
• слабая типизация, но начиная с 7-й версии появилась возможность установить режим строгой типизации

Сильные стороны языка:

• OPCache — in-memory хранилище байт-кода. Код приложения преобразовывается интерпретатором в инструкции для виртуальной машины Zend (байт-код, опкод),
  сохраняется в памяти и при последующих запусках Zend сразу берет готовый байт-код, минуя этапы чтения и преобразования кода приложения.
  Начиная с версии 5.5 входит в ядро, но для работы необходимо установить опцию в файле php.ini
• JIT-компилятор. Работает поверх OPCache, преобразовывает байт-код в машинные инструкции для процессора.
• Composer. Менеджер пакетов, сторонняя утилита, позволяет устанавливать в проект пакеты, контролирует зависимости и многое другое.
• PSR. Набор стандартов для разработчиков, делающий код проектов удобным для поддержки и использования.

Области, где PHP не является оптимальным выбором: асинхронные операции, хайлоад, обработка больших объемов данных, но многие проблемы языка можно
современными решениями.

Сообщение Что такое PHP? Какие основные области применения? появились сначала на mcodex.

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

Описание работы.

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

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

В сервисный класс добавляется метод (часто имеющий название accept), в который принимает объект посетителя как параметр и вызывает у него соответствующий метод.

Таким образом, в сервисные классы вносятся минимальные изменения (только принимающий метод), а весь дополнительный функционал реализуется в отдельном классе-посетителе.

Пример реализации

Есть CRM, в которой существуют разные типы записей — account, client, product, supplier и т.д. У каждого типа записи своя структура. Необходимо добавить реализацию экспорта всех записей в файл.

Для этого для каждого типа записи создается отдельный класс-посетитель, реализующий интерфейс Visitor с методом export.
В каждый класс записи добавляется метод accept, который принимает объект посетителя и вызывает его метод export.

В клиентском коде для экспорта у каждого экземпляра записи вызывается метод accept.

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

В данном примере метод accept можно вынести в базовый класс записей, так как его реализация одинакова для всех. Однако в реальных проектах это подходит не всегда и метод accept требуется реализовывать каждом классе.

Интрефейсы

// интерфейс для записей
interface Entity
{
    public function accept(Visitor $visitor): void;
}

// интерфейс для посетителей
interface Visitor
{
    public function export(Entity $entity): void;
}

// интерфейс для записей
interface Entity
{
    public function accept(Visitor $visitor): void;
}

// интерфейс для посетителей
interface Visitor
{
    public function export(Entity $entity): void;
}

Классы записей

class Product implements Entity
{
    protected string $title;
    protected float $price;

    public function accept(Visitor $visitor): void
    {
        $visitor->export($this);
    }
}


class Account implements Entity
{
    protected int $id;
    protected float $amount;

    public function accept(Visitor $visitor): void
    {
        $visitor->export($this);
    }
}

class Product implements Entity
{
    protected string $title;
    protected float $price;

    public function accept(Visitor $visitor): void
    {
        $visitor->export($this);
    }
}


class Account implements Entity
{
    protected int $id;
    protected float $amount;

    public function accept(Visitor $visitor): void
    {
        $visitor->export($this);
    }
}

Классы посетителей

class ProductVisitor implements Visitor
{

    public function export(Entity $entity)
    {
      // логика экспорта
    }
}


class ClientVisitor implements Visitor
{
    public function export(Entity $entity)
    {
      // логика экспорта
    }
}

class ProductVisitor implements Visitor
{

    public function export(Entity $entity)
    {
      // логика экспорта
    }
}


class ClientVisitor implements Visitor
{
    public function export(Entity $entity)
    {
      // логика экспорта
    }
}

Клиентский код

$product = new Product;
$account = new Account;

// делаем экспорт
$account->accept(new AccountVisitor);
$product->accept(new ProductVisitor);

$product = new Product;
$account = new Account;

// делаем экспорт
$account->accept(new AccountVisitor);
$product->accept(new ProductVisitor);

Ссылки:

https://github.com/maximmas/patterns

https://refactoring.guru/ru/design-patterns

Сообщение Шаблон «Посетитель (Visitor)» появились сначала на mcodex.

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

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

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

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

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

Внешний ключ не является обязательным. Можно просто добавить столбец со значениями идентификаторов из связанной таблицы, не указывая, что это внешний ключ.
Но если такой столбец назначить внешним ключом, то на таблицу накладывается так называемое «ограничение» (constrains) — жесткое правило, гарантирующее, что в связанной таблице точно есть нужные данные. Такое ограничение используется для обеспечения «ссылочной целостности (консистентости)» базы данных — гарантии, что свзязи указывают на существующие данные.

Пример таблиц

Articles

Categories

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

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

Формат

SELECT поля_таблиц
FROM таблица_1
JOIN таблица_2
    ON условие_соединения
JOIN таблица_3
    ON условие_соединения
...    

SELECT поля_таблиц
FROM таблица_1
JOIN таблица_2
    ON условие_соединения
JOIN таблица_3
    ON условие_соединения
...    

Пример простого соединения 2-х таблиц (статьи и категории):

SELECT articles.id, articles.title, categories.name 
FROM articles
JOIN categories
  ON categories.id = articles.category_id;

SELECT articles.id, articles.title, categories.name 
FROM articles
JOIN categories
  ON categories.id = articles.category_id;

В результате будут выведены все заголовки статей и их категории.

Если нужны все столбцы из articles:

SELECT articles.*, categories.name 
FROM articles
JOIN categories
  ON categories.id = articles.category_id;

SELECT articles.*, categories.name 
FROM articles
JOIN categories
  ON categories.id = articles.category_id;

Если нужны все столбцы из обеих таблиц:

SELECT *
FROM articles
JOIN categories
  ON categories.id = articles.category_id;

SELECT *
FROM articles
JOIN categories
  ON categories.id = articles.category_id;

Соединение может быть внутренним (INNER) или внешним (OUTER)
Если тип соединения не указан, то по умолчанию используется внутреннее соединение.
Внешнее соединение может быть левое (LEFT) или правое (RIGHT)
Для внешнего соединения модификатор OUTER можно не указывать, тип (LEFT/RIGHT) — обязательно.

Примеры указания типов:
INNER JOIN — явно указано внутренне соединение
JOIN — тип не указан, то же самое, что INNER JOIN
LEFT OUTER JOIN = LEFT JOIN
RIGHT OUTER JOIN = RIGHT JOIN

Разница между типами соединений.

1. Внутреннее соединение возвращает только те строки, для которых выполняется условие соединения.
   В примере: статьи, у которых есть категории. Если в статье указана несуществующая категория — такая запись не попадет в результат.

Внутреннее соединение можно релизовать через оператор WHERE

SELECT articles.id, articles.title, categories.name 
FROM articles, categories
WHERE articles.category_id = categories.id;

SELECT articles.id, articles.title, categories.name 
FROM articles, categories
WHERE articles.category_id = categories.id;

2. Внешнее соединение возвращает все строки. Если условие не выполняется (в статье ссылка на несущуствующую категорию) в итогой таблице вместо значений будет подставленно NULL.

Варианты внешнего соединения:
LEFT JOIN — берутся все записи из левой таблицы, из правой — только совпавшие по условию соединения
RIGHT JOIN — берутся все записи из правой таблицы, из левой — только совпавшие по условию соединения

Положение таблицы (левая или правая) определяется ее позицией в запросе. Та что стоит первая - левая.

SELECT * 
FROM левая_таблица l
LEFT JOIN правая_таблица r
ON l.user_id = r.id;

SELECT * 
FROM левая_таблица l
LEFT JOIN правая_таблица r
ON l.user_id = r.id;

Пример LEFT JOIN

SELECT a.*, c.name 
FROM articles a
LEFT JOIN categories c
ON a.category_id = c.id;

SELECT a.*, c.name 
FROM articles a
LEFT JOIN categories c
ON a.category_id = c.id;

В результате будут выведены все статьи, если у статьи нет категории — в c.name будет NULL
Если у категории нет статьи — категория не появится в результатах.

Пример RIGHT JOIN

SELECT a.*, c.name 
FROM articles a
RIGHT JOIN categories c
ON a.category_id = c.id;

SELECT a.*, c.name 
FROM articles a
RIGHT JOIN categories c
ON a.category_id = c.id;

В результате будут выведены все категории, если у категории нет статьи — в столбцах a.* будет NULL
Тот же результат можно получить через LEFT JOIN, поменяв таблицы местами, поэтому на практике RIGHT JOIN редко используется.

Еще раз: LEFT JOIN - выводим все строки из первой таблицы, а из второй те, для которых выполняется условие соединения.

Фильтрация результатов с помощью оператора WHERE.

Порядок выполнения таких запросов:
FROM
JOIN
WHERE
SELECT

Пример:
Необходимо вывести названия и ID всех категорий, в которых нет статей.

Решение

SELECT c.id, c.name
FROM categories c
LEFT JOIN articles a
  ON c.id=a.category_id
WHERE a.id IS NULL;

SELECT c.id, c.name
FROM categories c
LEFT JOIN articles a
  ON c.id=a.category_id
WHERE a.id IS NULL;

Как работает:
Шаг 1. FROM .. JOIN ..
Создается соединение, в результате получается промежуточная таблица со всеми строками из таблицы категорий. Столбцы — все из обеих таблиц. Если у категории нет статьи — в ячейках (id, title, text, …) значение NULL
Шаг 2. Применяется фильтр WHERE, остаются только строки с aricles.id = NULL
Шаг 3. Применяется SELECT, остаются только categories.id/name.

Сообщение Соединение таблиц через JOIN в MySQL появились сначала на mcodex.

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

Роль спред-оператора.

Спред-оператор в JavaScript является синтаксической конструкцией, позволяющей передавать элементы итерируемых коллекций (например, массивы, строки или объекты) в другие итерируемые коллекции или функции.
Он указывается в виде трех точек “…”, за которыми следует выражение или коллекция.
Спред-оператор — это мощный инструмент, предоставляющий краткий и гибкий способ работы с
данными в JavaScript. Его можно использовать для соединения массивов, создания
поверхностных копий массивов, преобразования строк в массивы символов, соединения или клонирования объектов, а также для динамической передачи значений в функции или конструкторы, включая множество других способов применения.
Благодаря спред-оператору многие операции становятся проще и выразительнее, поэтому он и получил широкую популярность среди JavaScript-разработчиков.

Синтаксис и использование спред-оператора в JavaScript

Чтобы продемонстрировать синтаксис спред-оператора, давайте рассмотрим несколько примеров его применения при работе с массивами, строками и объектами.

1. Соединение массивов

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

Пример:

const originalArray = [[1, 2, 3, 4], 12];​
const copiedArray = [...originalArray];​
​
copiedArray[0].push(99);​
​
console.log(originalArray); // [[1, 2, 3, 4, 99], 12]​
console.log(copiedArray); // [[1, 2, 3, 4, 99], 12]​

const originalArray = [[1, 2, 3, 4], 12];​
const copiedArray = [...originalArray];​
​
copiedArray[0].push(99);​
​
console.log(originalArray); // [[1, 2, 3, 4, 99], 12]​
console.log(copiedArray); // [[1, 2, 3, 4, 99], 12]​

2. Преобразование строк

Спред-оператор можно использовать для преобразования строки в массив её символов. Это делает работу со строками удобнее: получив массив символов, вы можете применять к нему методы массивов или объединять его с другими массивами.

Пример:

const str = "Hello";​
​
const charArray = [...str];​
console.log(charArray); // ['H', 'e', 'l', 'l', 'o']​

const str = "Hello";​
​
const charArray = [...str];​
console.log(charArray); // ['H', 'e', 'l', 'l', 'o']​

3. Соединение и клонирование объектов

Спред-оператор можно использовать для передачи свойств из одного объекта в другой. Это помогает при соединении или клонировании объектов. Создается новый объект, в котором
некоторые свойства могут быть переопределены. Также можно извлекать из объекта нужные свойства.

Пример:​

const obj1 = { a: 1, b: 2 };​
const obj2 = { b: 3, c: 4 };​
​
// Соединение объектов​
const mergedObj = { ...obj1, ...obj2 };​
console.log(mergedObj); // Output: { a: 1, b: 3, c: 4 }​
​
// Клонирование​
const clonedObj = { ...obj1 };​
console.log(clonedObj); // Output: { a: 1, b: 2 }​

const obj1 = { a: 1, b: 2 };​
const obj2 = { b: 3, c: 4 };​
​
// Соединение объектов​
const mergedObj = { ...obj1, ...obj2 };​
console.log(mergedObj); // Output: { a: 1, b: 3, c: 4 }​
​
// Клонирование​
const clonedObj = { ...obj1 };​
console.log(clonedObj); // Output: { a: 1, b: 2 }​

4. Передача аргументов в функции.

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

Пример:​

const numbers = [1, 2, 3];​
const sum = (a, b, c) => a + b + c;​

console.log(sum(...numbers)); // 6​

const numbers = [1, 2, 3];​
const sum = (a, b, c) => a + b + c;​

console.log(sum(...numbers)); // 6​

5. Объединение спред-оператора с остаточным параметром

Мощь функционального программирования особенно заметна, когда спред-оператор используется вместе с другими современными возможностями JavaScript — например, с деструктуризацией массивов и объектов. Такой подход позволяет легко извлекать и обрабатывать элементы массивов или свойства объектов, используя краткий и выразительный синтаксис.

Пример:​

const numbers = [1, 2, 3, 4, 5];​
const [first, second, ...rest] = numbers;​
​
console.log(first); // 1​
console.log(second); // 2​
console.log(rest); // [3, 4, 5]​

const numbers = [1, 2, 3, 4, 5];​
const [first, second, ...rest] = numbers;​
​
console.log(first); // 1​
console.log(second); // 2​
console.log(rest); // [3, 4, 5]​

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

Еще немного о спред-операторе и поверхностном копировании​.

Необходимо отметить, что с помощью спред-оператора можно создавать поверхностные копии массивов и объектов, а также увеличить производительность при создании больших массивов и
объектов.​

Пример

const originalArray = [[1, 2, 3, 4], 12];​
const copiedArray = [...originalArray];​

copiedArray[0].push(99);

​console.log(originalArray); // [[1, 2, 3, 4, 99], 12]​
console.log(copiedArray); // [[1, 2, 3, 4, 99], 12]

const originalArray = [[1, 2, 3, 4], 12];​
const copiedArray = [...originalArray];​

copiedArray[0].push(99);

​console.log(originalArray); // [[1, 2, 3, 4, 99], 12]​
console.log(copiedArray); // [[1, 2, 3, 4, 99], 12]

В этом коде originalArray состоит из двух элементов. С помощью спред-оператора мы создаем новый массив copiedArray и переносим в него элементы исходного массива. Затем мы изменяем первый элемент copiedArray, добавив число 99 с помощью метода push().

После вывода copiedArray мы видим, что к первому элементу массива было добавлено 99, но есть проблема с поверхностным копированием, которое делает спред-оператор. Изменения в copiedArray оказывают влияние на originalArray.

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

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

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

3 полезных совета для оптимизации производительности и избежания распространенных ошибок.

Для оптимизации производительности и избежания распространенных ошибок при работе со спред-оператором используйте следующие рекомендации:

1.​ Не используйте спред-оператор для передачи элементов больших массивов или объектов в критичных для производительности участках кода.

2. Помните о возможных побочных эффектах при передаче вложенных объектов. При необходимости рассмотрите возможность использования методов глубокого
клонирования.

3. Пользуйтесь спред-оператором разумно и, если производительность имеет значение, рассмотрите альтернативные подходы.

Резюме

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

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

Оригинал статьи:

https://kinsta.com/knowledgebase/spread-operator-javascript

Сообщение Спред-оператор в JavaScript появились сначала на mcodex.