This is the process I use for deploying a Laravel application to Bitbucket. Once I setup the Debian server with Caddy
and PHP-FPM
it is usually ready to go.
- Install Caddy
- Install PHP-FPM
mkdir -p /var/builds/staging.example.com && mkdir -p /var/www
- Create
.env
andstorage
folder in/var/builds/staging.example.com
- The
deploy.sh
script will symlink to the builds folder
- The
- Configure Caddy and test configuration
Once that is done you can configure your Bitbucket pipeline. I will make a YouTube on the overall process and post it here.
Pipelines runs on pushes
to master
. The pushes are done through a pull request and executes the commmands in ./bitbucket-pipelines.yml
. You
can see the pipeline status on bitbucket.org. The
Bitbucket Repository will require the following variables setup to work properly. These are located under
Repository Settings -> Repository Variables
Repository Variable | Setup in Bitbucket | Description |
---|---|---|
USER |
ubuntu | Bitbucket uses this user to execute SSH and SCP commands. |
BUILD_PATH |
staging.example.com | The relative path to drop the ZIP file in /var/builds/$BUILD_PATH which is defined in bitbucket-pipelines.yml |
SERVER |
staging.example.com | Server Bitbucket will use for sending ZIP file to and executing commands |
SSH_PORT |
2222 | Port used for SCP and SSH commands |
SSH_DEBUG |
false | Debug the SSH connection by setting to true |
- The pipeline builds the project with npm and composer.
- Composer tests are run in the docker container the pipeline has build
- Successful builds create two artifacts. One build.zip and the deploy.sh file.
- Bitbucket uploads the build.zip and deploy.sh to the
BUILD_PATH
on the remoteSERVER
specified. - Bitbucket then calls
deploy.sh
with the appropriate SHA and branch and your app is deployed! 🚀🚀🚀
deploy.sh
is a script that is used for the atomic deployments. An atomic deployment simply changes the symlink for the
webserver and then restarts the webserver after running any database migrations. This process, like all processes, can
always be improved upon. An atomic deployment allows a server administrator to symlink to a prior version of working
code as long as they navigate to the correct git SHA and change the symlink. In the future the deploy.sh script could
probably perform a database backup before a migration is applied.
If the pipeline fails you can test locally with Docker. Bitbucket has decent documentation for doing this. They also have a link that discusses "Troubleshooting locally with Docker". Below is an example of how I was able to troubleshoot the pipeline issues.
docker build --memory=1g --memory-swap=1g -t chris/bbtermin:tag -f my.dockerfile .
docker run --network=host --name bbmysql -e MYSQL_DATABASE='laravel' -e MYSQL_ROOT_PASSWORD='password' -e MYSQL_ROOT_HOST='%' -e MYSQL_USER='sail' -e MYSQL_PASSWORD='password' -d mysql:8.0
docker run -it --network=host --memory=4g --memory-swap=4g --memory-swappiness=0 --cpus=4 --entrypoint=/bin/bash chris/bbtermin:tag
If you receive an error about the container being used for mysql - you can docker rm container-name
and restart.
You can also ignore any error about the kernel not supporting memory swappiness