This is not an in-depth article — have too much going on these days for that.  It is a more a short-hand techie crib sheet of how I got a deployment repo to auto-pull the latest changes to its develop branch over to my staging server automatically.    This is pulling down a fully software environment to a directory on the server.

SSH keys for Bitbucket to login to the server

Create the repo.

Go to pipeline and SSH keys.

Add a fingerprint for the server you are deploying to by typing in the host name.  Must be a public server not behind a firewall, web proxy, etc.   It can be but that means you need to know how to authorize Bitbucket for access via whitelist.  I skipped that step and went direct.

Generate an SSH key as well using the web interface.

Copy that key.

Add a bitbucket user on the server

You’ll need super admin access to your server.

Create a new user.

Make sure they are in a group that has RWX access to the directory where you want to deploy code.    RWX for directories, RW as a minimum for files.

In my case I had to make sure the user was both in their own group (for SSH file security) and the www-stuff group so they could write to a website dir.

Create the .ssh directory for the user.   Permissions: 700 user/group owned by the bitbucket user.

Create the authorized_keys file for the user and paste in that Bitbucket public key you copies.   Permissions: 600

Generate a public key for the user and copy the contents, usually in id_rsa.pub so you can put it on your repo.

The deployment script

Put a deployment shell script in the home directory for the user.

For example, a script that goes to the website directory for the staging site, pulls down the latest repo updates with a git pull and logs it.  Don’t forget to chmod a+x on this one.

Setup the staging repo

Go to the directory where the staging site code is going to end up, the “public HTML” directory.

Clone (or pull if it is already in place) the deployment repo there.

Make sure the development branch is checked out for a staging site.

For a WordPress site make sure your repo does not have wp-config.php or wp-content/uploads in the repo.   This should be ignored with a .gitignore file.   The full “standard template” of what to ignore on a WordPress site repo:

In my case I had an existing site so I moved the entire public HTML to a backup location so I could easily copy over the wp-config.php and other “do not include” files and not lose any content after a “clean deployment repo pull”.

Add read-only for the new user to the repo

Go back to Bitbucket and on that deployment repo, the one you will clone into the staging site, add SSH access (not in the pipeline area, on the repo itself).  This will allow read-only access to the repo from the server where you just created that id_rsa.pub public key.

You can test this by sudo’ing to that user on the server and running your shell script.   It should create the log file and updated.txt file if it ran properly.

Add the Bitbucket Pipeline YAML file

The “Magic” to get pipelines working is to add the bitbucket-pipelines.yml file to your repo’s root directory.

If you’ve setup a pipeline by adding a fingerprint and/or generating an SSH key it will auto-activate the pipeline feature.  Now whenever you publish a change to that repo Bitbucket will look for this file.  If it is present it will run the commands within.

Here is the simple version of getting Bitbucket to login as the new bitbucket user on a staging server and run that deploy_staging.sh script we created earlier.  That script will go to the staging site public HTML directory and pull down that latest copy of the deployment repo using the develop branch as its point of reference.

 

Share Your Insight

%d bloggers like this: