Для распределенной разработки используют GitHub и GitHub Action. Код темы и/или плагинов должен находиться в репозитории для отслеживания версий, командной работы и т.п. Разработка новой фичи ведется в отдельной ветке. При смерживании этой ветки в мастер выполняется код на GitHub Actions, который заливает изменения на продакшн сайт. Это достигается наличием в репозитории примерно такого файла .github/workflows/prod.yml
:
name: Deploy to Production
on:
push:
branches:
- master
jobs:
release:
name: Deploy to Production
runs-on: ubuntu-latest
strategy:
matrix:
os: [ ubuntu-latest ]
php-version: [ '7.4' ]
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Get Composer cache directory
id: composer-cache
run: echo "::set-output name=dir::$(composer config cache-files-dir)"
- name: Set up Composer caching
uses: actions/cache@v3
env:
cache-name: cache-composer-dependencies
with:
path: ${{ steps.composer-cache.outputs.dir }}
key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
restore-keys: |
${{ runner.os }}-composer-
- name: Install PHP
uses: shivammathur/setup-php@v2
with:
php-version: ${{ matrix.php-version }}
env:
COMPOSER_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Install dependencies in prod version
run: |
composer config github-oauth.github.com ${{ secrets.GITHUB_TOKEN }}
composer install --no-dev
env:
COMPOSER_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Build JS ans CSS
run: |
npm install
npm run build
npm run build-css
- name: Deploy the code to the production server
uses: burnett01/rsync-deployments@5.2
with:
switches: -cvzr --delete --exclude-from=.distignore
path: ${{ env.GITHUB_WORKSPACE }}
remote_path: ${{ secrets.REMOTE_PATH }}
remote_host: ${{ secrets.REMOTE_HOST }}
remote_user: ${{ secrets.REMOTE_USER }}
remote_key: ${{ secrets.REMOTE_KEY }}
Secrets должны быть установлены в GitHub и содержать, соответственно, путь к папке WordPress на сервере, имя/IP хоста, имя пользователя, под которым будут записываться файлы и его ключ.
Таким образом, файлы при разработке идут снизу вверх (от локальной машины на продакшен сервер).
База, напротив, должна идти сверху вниз - все изменения вносятся на сервере, а разработчики скачивают эти изменения для обновления на локальных машинах. Кроме того, сверху вниз скачиваются файлы uploads.
Для синхронизации локального сайта с сервером может быть использован следующий файл sync-site
.
#!/bin/bash
#set -x
if [ "$OSTYPE" == "linux-gnu" ] && grep -q Microsoft /proc/version; then
WP_PATH=$(wp config path)
else
WP_PATH=$(wp config path 2>/dev/null)
fi
if [[ ! $WP_PATH ]]; then
echo "This is not a WordPress install"
exit 1
fi
WP_PATH="$(dirname "$WP_PATH")"
PARAMETERS_FILE=""$WP_PATH/sync.params""
if [[ ! -f "$PARAMETERS_FILE" ]]; then
echo "Parameters file $PARAMETERS_FILE does not exist"
exit 1
fi
TYPE="$1"
if [[ -z $TYPE ]]; then
TYPE="db"
fi
if [[ "db" != "$TYPE" && "plugins" != "$TYPE" && "uploads" != "$TYPE" && "all" != "$TYPE" ]]; then
echo "Argument can be 'db', 'plugins', 'uploads' or 'all' only"
exit 1
fi
# shellcheck disable=SC1090
if ! source "$PARAMETERS_FILE";
then
exit 1
fi
if [[ "" == "$REMOTE_USER" ]]; then
REMOTE_USER=$USER
fi
SECONDS=0
if [[ "db" == "$TYPE" || "all" == "$TYPE" ]]; then
echo -e "\nSyncing database..."
ssh -l "$REMOTE_USER" -i "$KEY_FILE" "$REMOTE_DOMAIN" "cd $REMOTE_PATH > /dev/null&&/usr/local/bin/wp db export /tmp/wp.sql > /dev/null"
scp -i "$KEY_FILE" "$REMOTE_USER"@"$REMOTE_DOMAIN":/tmp/wp.sql wp.sql
ssh -l "$REMOTE_USER" -i "$KEY_FILE" "$REMOTE_DOMAIN" "rm /tmp/wp.sql"
echo -e "Done."
echo -e "\nImporting database..."
wp --quiet db import wp.sql
echo -e "Done."
rm wp.sql
echo -e "\nReplacing domain in database..."
wp search-replace --url="$REMOTE_URL" "$REMOTE_URL" "$LOCAL_URL" --recurse-objects --report-changed-only --precise --skip-columns=guid --skip-tables=wp_users --skip-plugins --skip-themes --allow-root
wp cache flush
echo -e "Done."
fi
if [[ "plugins" == "$TYPE" || "all" == "$TYPE" ]]; then
if [ "$OSTYPE" == "linux-gnu" ] && grep -q Microsoft /proc/version; then
# Fix paths if we are in Windows Subsystem Linux (WSL)
LOCAL_PATH=$(wslpath "$LOCAL_PATH")
fi
echo -e "\nSyncing plugins..."
IFS=' '
read -ra PLUGINS <<< "$SYNC_PLUGINS"
for PLUGIN in "${PLUGINS[@]}"; do
rsync -ase "ssh -l $REMOTE_USER -i $KEY_FILE" "$REMOTE_USER"@"$REMOTE_DOMAIN":"$REMOTE_PATH"/wp-content/plugins/"$PLUGIN"/* "$LOCAL_PATH"/wp-content/plugins/"$PLUGIN"
done
echo -e "Done."
fi
if [[ "uploads" == "$TYPE" || "all" == "$TYPE" ]]; then
if [ "$OSTYPE" == "linux-gnu" ] && grep -q Microsoft /proc/version; then
# Fix paths if we are in Windows Subsystem Linux (WSL)
LOCAL_PATH=$(wslpath "$LOCAL_PATH")
fi
echo -e "\nSyncing uploads..."
rsync -ase "ssh -l $REMOTE_USER -i $KEY_FILE" --exclude "*backwpup*/*" "$REMOTE_USER"@"$REMOTE_DOMAIN":"$REMOTE_PATH"/wp-content/uploads/* "$LOCAL_PATH"/wp-content/uploads
echo -e "Done."
fi
echo -e "\nDoing after sync commands..."
$AFTER_SYNC_COMMANDS
echo -e "Done."
echo -e "\nFinished. Time elapsed: $SECONDS seconds."
Ну и для вызова его под Windows sync-site.bat
.
@echo off
call bash sync-site %*
Файлы надо поместить где-то в PATH. В корневой папке локального сайта надо добавить файл параметров sync.params
.
REMOTE_DOMAIN="xxx.xxx.xxx.xxx"
KEY_FILE="~/.ssh/user-key.rsa"
REMOTE_PATH="/var/www/site-dir/"
LOCAL_PATH="/mnt/d/site-dir"
REMOTE_URL="https://my-site.com"
LOCAL_URL="https://my-site.test"
AFTER_SYNC_COMMANDS="wp plugin deactivate backwpup cloudflare ewww-image-optimizer wordfence wp-super-cache && wp option delete otgs_wpml_tm_ate_cloned_site_lock"
sync-site db
обновит базу на локалке
sync-site uploads
обновит папку uploads
sync-site plugins
обновит плагины (это нужно для случаев, когда платные плагины имеют привязку только к серверу)
sync-site all
обновит все вышеперечисленное.