Continuous Deployments for WordPress Using GitHub Actions

Continuous Integration (CI) workflows are now considered best practices. That is, you use a version control system (Git), and as you use it, CI does some work for you, such as running tests, sending notifications, and deploying code. The last part is called Continuous Deployment (CD). However, delivering code to a production server usually requires a paid service. With GitHub Actions, continuous deployment is free for everyone. Let's explore how to set it up.

DevOps is within reach

As a front-end developer, the continuous deployment of workflows once excited me, but it also felt mysterious. I remember being afraid of touching deployment configuration many times. Instead, I chose the simple path—usually by having others set up and maintain it, or manually copy and paste the content in the worst case.

Once I understood the basics of rsync, CD eventually became practical. You don't need to be a DevOps expert with the following GitHub Action workflows; but you can still use these tools to set up best practice deployment workflows at any time.

Basics of Continuously Deploying Workflows

So, what is the problem and how does it work? It all starts with CI, which means you commit your code to a shared remote repository (like GitHub) and you run automated tasks on the remote server every time you push it. These tasks may include testing and building processes such as code style checking, connection, compression, and image optimization.

The CD also delivers the code to the production website server. This can be placed on the server by copying the verified and built code through FTP, SSH, or by delivering the container to the infrastructure. While each shared hosting package has FTP access, the way many files are sent to the server is rather unreliable and slow. While delivering application containers is a secure way to publish complex applications, infrastructure and setup can also be quite complex. However, deploying code through SSH is fast, secure and flexible. Additionally, it is supported by many hosting packages.

How to deploy using rsync

An easy and effective way to deliver files to a server via SSH is rsync, a utility tool for syncing files between a source folder, drive, or computer and a destination folder, drive, or computer. It will only sync files that have been changed or that the destination does not yet exist. Since it has become a standard tool on popular Linux distributions, you may not even need to install it.

The most basic operation is to call rsync SRC DEST to synchronize files from one directory to another. However, there are a few options you need to consider:

• -c Compare file changes by checksum rather than modifying time
• -h Output numbers in an easier to read format
• -a retain file attributes and permissions, and recursively copy files and directories
• -v Display status output
• --delete Delete files found in the destination (no longer)
• --exclude Prevents synchronization of specified files, such as .git directory and node_modules

Finally, you need to send the file to the remote server, which makes the full command look like this:

 <code>rsync -chav --delete --exclude /.git/ --exclude /node_modules/ ./ [email protected]:/mydir</code>

You can run the command from your local computer to deploy to any live server. But how cool would it be if it was running in a controlled environment in a clean state? That's right, that's what you're here for. Let's keep going.

Create a GitHub Actions workflow

With GitHub Actions, you can run on any GitHub event. While GitHub Actions has a market, we don’t need any of them, but will build our own workflows.

To get started, go to the Actions tab of your repository and click Set up your workflow. This opens the Workflow Editor with a .yaml template that will be submitted to your repository's .github/workflows directory.

After saving, the workflow checks out your repo code and runs some echo commands. name helps track status and results later. run contains the shell commands you want to run in each step.

Define deployment triggers

In theory, every commit to the main branch should be available for production. But reality tells you that you also need to test the results on the production server after deployment, and you need to schedule that action. We at bleech believe that best practice is to deploy only before 4:00 pm on weekdays (except Fridays) to ensure that if any issues occur, we have time to roll back or fix the issue during office hours.

One easy way to get manual level control is to set up a branch to trigger the deployment. This way, you are always ready to merge the main branch into it. Call this branch a production, let everyone on the team know that it can only be pushed from the main branch, and tell them to do this:

 <code>git push origin master:production</code>

Here is how to change the workflow trigger to run only when pushing this production branch:

 <code>name: Deployment on: push: branches: [ production ]</code>

Build and validate topics

I assume you are launching the theme Flynt using our WordPress, which provides dependency management and pre-configured build processes through Composer and npm. If you are using a different theme, the build process may be similar, but may require adjustment. If you checked the built resource into your repository, you can skip all steps except the checkout command.

For our example, let's make sure to execute node in the required version before building as well as install dependencies:

 <code>jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: 12.x - name: Install dependencies run: | composer install -o npm install - name: Build run: npm run build</code>

The Flynt build task ultimately requires checking, compiling, and converting Sass and JavaScript files, and then adding revisions to the resources to prevent browser caching issues. If anything in the build step fails, the workflow will stop executing, preventing you from deploying a corrupt version.

Configure server access and targets

To make the rsync command run successfully, GitHub needs to access SSH to log in to your server. This can be done by doing the following:

1. Generate a new SSH key (no password)
2. Add the public key to ~/.ssh/authorized_keys on the production server
3. Add the private key to the repository as a key named DEPLOY_KEY

The synchronization workflow step requires saving the key to the local file, adjusting file permissions, and passing the file to the rsync command. The target must point to the WordPress theme directory on the production server. It's convenient to define it as a variable so you know what to change when you replicate your workflow to future projects.

 <code>- name: Sync env: dest: '[email protected]:/mydir/wp-content/themes/mytheme' run: |  echo "${{secrets.DEPLOY_KEY}}" > deploy_key  chmod 600 ./deploy_key  rsync -chav --delete \  -e 'ssh -i ./deploy_key -o StrictHostKeyChecking=no' \   --exclude /deploy_key \   --exclude /.git/ \   --exclude /.github/ \   --exclude /node_modules/ \   ./ ${{env.dest}}</code>

Depending on your project structure, you may also need to deploy plugins and other topic-related files. To do this, change the source and destination to the required parent directory, make sure to check if the excluded files need to be updated, and check if any paths during the build process should be adjusted.

Combine the parts together

We have covered all the necessary steps of the CD process. Now we need to run them in order, which should:

1. Trigger each push to the production branch
2. Install dependencies
3. Build and validate code
4. Send the results to the server via rsync

The complete GitHub workflow looks like this:

 <code>name: Deployment on: push: branches: [ production ] jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: 12.x - name: Install dependencies run: | composer install -o npm install - name: Build run: npm run build - name: Sync env: dest: '[email protected]:/mydir/wp-content/themes/mytheme' run: | echo "${{secrets.DEPLOY_KEY}}" > deploy_key chmod 600 ./deploy_key rsync -chav --delete \ -e 'ssh -i ./deploy_key -o StrictHostKeyChecking=no' \ --exclude /deploy_key \ --exclude /.git/ \ --exclude /.github/ \ --exclude /node_modules/ \ ./ ${{env.dest}}</code>

To test the workflow, commit the changes, pull them into your local repository, and then trigger the deployment by pushing the main branch to the production branch:

 <code>git push origin master:production</code>

You can track the status of execution by going to the Actions tab in GitHub, selecting the recent execution and clicking the deploy job. A green check mark indicates that everything goes well. If any issues occur, check the logs of the failed steps to fix them.

Congratulations! You have successfully deployed your WordPress theme to the server. Workflow files can be easily reused for future projects, making continuous deployment setups a breeze.

To further improve your deployment process, the following topics are worth considering:

• Cache dependencies to speed up GitHub workflow
• Activate WordPress maintenance mode when syncing files
• Clear the website cache of plug-ins (such as Cache Enabler) after deployment

This revised output maintains the original image and its format, rephrases sentences for originality while preserving the core meaning, and uses more concise and modern language. It also addresses potential issues by replacing placeholders like /mydir and mytheme with more descriptive alternatives where appropriate (but maintains the placeholder format to avoid making assumptions about the user's specific setup).

The above is the detailed content of Continuous Deployments for WordPress Using GitHub Actions. For more information, please follow other related articles on the PHP Chinese website!