Chapter 9: Workflow: Developing Locally and Pushing to Live

In web development, it’s common to develop and test code locally before pushing changes to a live environment. In this chapter, we’ll cover traditional methods like FTP and SFTP for file transfers, and introduce automated Continuous Integration/Continuous Deployment (CI/CD) workflows using GitHub webhooks to streamline the process.

File Transfers: FTP vs. SFTP

File Transfer Protocol (FTP) and Secure File Transfer Protocol (SFTP) are commonly used methods for transferring files between your local machine and a remote server. Depending on your hosting provider, you may have access to FTP, SFTP, or both. Here’s a quick overview of each:

FTP (File Transfer Protocol): A standard protocol for transferring files, but it lacks encryption, meaning data (including login credentials) is transferred in plain text.
SFTP (Secure File Transfer Protocol): Uses SSH (Secure Shell) to encrypt data during transfer, providing a secure alternative to FTP. SFTP is recommended for transferring sensitive files securely.

Setting Up an FTP/SFTP Client

To use FTP or SFTP, you’ll need a client like FileZilla or Cyberduck. Here’s how to set up a connection:

Install an FTP/SFTP client (e.g.,Core FTP, FileZilla or Cyberduck).
Open the client and create a new connection profile.
Enter your server’s IP address or domain, FTP/SFTP port (typically port 21 for FTP and 22 for SFTP), and login credentials.
Click "Connect" to establish the connection and transfer files between your local machine and the server.

Transferring Files via FTP/SFTP

After establishing a connection, you can upload or download files to and from the server by dragging them between the local and remote directories within your FTP/SFTP client. Be sure to check with your hosting provider for specific folder structures, as many hosts have designated folders for live website files (e.g., public_html).

Web Development - Local Development and Live Deployment

Automating Deployments with CI/CD

Continuous Integration and Continuous Deployment (CI/CD) is a modern workflow that automates the process of testing and deploying code. In a CI/CD pipeline, code changes are automatically tested and deployed to a live environment when they’re pushed to a designated branch (such as main or production). Using CI/CD, you can avoid the manual file transfer process and reduce the risk of errors.

Setting Up CI/CD with GitHub Actions

GitHub Actions is a tool that enables CI/CD directly within GitHub. With GitHub Actions, you can define workflows to automate the testing and deployment process. Here’s a basic example to deploy a static site using GitHub Actions:

        # .github/workflows/deploy.yml
        name: Deploy to Production
        
        on:
          push:
            branches:
              - main
        
        jobs:
          deploy:
            runs-on: ubuntu-latest
            steps:
              - name: Checkout code
                uses: actions/checkout@v2
        
              - name: Deploy to server
                env:
                  HOST: ${{ secrets.SSH_HOST }}
                  USERNAME: ${{ secrets.SSH_USERNAME }}
                  PASSWORD: ${{ secrets.SSH_PASSWORD }}
                run: |
                  scp -r * $USERNAME@$HOST:/path/to/deployment/directory

In this example, GitHub Actions listens for pushes to the main branch. When a push is detected, it deploys the contents of the repository to a specified server directory using scp. Note that sensitive information like the host, username, and password is stored securely as GitHub Secrets.

Using GitHub Webhooks for Automated Deployments

GitHub webhooks can also be used to trigger CI/CD processes on external servers. A webhook is a URL endpoint that GitHub notifies when certain events (e.g., pushes) happen in a repository. When integrated with a CI/CD server, a webhook can trigger the deployment process automatically upon new code pushes.

Setting Up a GitHub Webhook

To set up a webhook in GitHub, follow these steps:

Go to your GitHub repository and click on Settings.
Under Webhooks, click Add webhook.
Enter the payload URL, which is the endpoint where your server will listen for webhook events (e.g., https://yourserver.com/deploy).
Select application/json as the content type and choose Push events as the trigger event.
Click Add webhook to complete the setup.

Setting Up the Server to Receive Webhooks

To receive webhooks and automatically deploy code, your server must have an endpoint configured to handle the webhook payload. Here’s a simple example of a webhook receiver script using PHP:

        <?php
        // deploy.php - Script to automate deployment via GitHub webhook
        $payload = json_decode(file_get_contents('php://input'), true);
        
        if ($payload['ref'] === 'refs/heads/main') {
            // Execute deployment commands
            shell_exec('cd /path/to/your/project && git pull origin main');
            echo 'Deployment triggered!';
        } else {
            echo 'No deployment for this branch.';
        }
        ?>

This script checks if the push event was for the main branch and, if so, pulls the latest code from GitHub. Place this file on your server at the webhook URL you specified in GitHub, and set permissions to allow the web server to run Git commands.

The Importance of Testing Before and After Deployment

Testing code thoroughly before deploying it to a live environment is crucial to maintaining a stable and functional website. Even minor changes can sometimes lead to unexpected issues, so it’s important to check that all new features and modifications work as intended before going live. Here’s why testing is essential:

Identify Bugs Early: Testing locally or in a staging environment helps catch errors or bugs before they impact real users.
Ensure Compatibility: Confirm that new code integrates well with existing functionality and doesn’t introduce compatibility issues.
Protect User Experience: Testing helps ensure that new features don’t disrupt the user experience, which could lead to lost visitors or users.

Verifying the Site After an Update

After deploying changes to your live site, it’s equally important to verify that everything is working as expected in the live environment. The following checks are recommended to ensure a successful deployment:

Run a Smoke Test: Check critical functions of the website (e.g., forms, navigation, login) to verify that they work as expected post-deployment.
Inspect UI and Layout: Ensure that the layout and user interface elements display correctly and that no styling issues have been introduced.
Monitor Performance: Check the site’s loading speed and overall performance, as some changes can unintentionally affect site efficiency.
Review Error Logs: Look at server logs for any unexpected errors or warnings that may have occurred during the deployment.

Testing before and after deploying code is essential for delivering a reliable, high-quality user experience. By establishing a consistent testing routine, you can deploy changes confidently, knowing that your site remains functional and user-friendly.

Summary

Developing locally and pushing to live environments involves either manual file transfers (using FTP/SFTP) or automated deployments (using CI/CD or GitHub webhooks). While FTP/SFTP offers control over individual files, CI/CD workflows streamline deployments and reduce manual effort. With GitHub Actions or webhooks, you can create a reliable, automated deployment pipeline that triggers updates to your live site whenever you push code to your main branch.