Introduction
In this fast-paced world, where everything seems to be happening quickly, it is paramount for early as well as frequent deployment of websites/apps to keep up with the competition. There are various ways of deploying your web apps to your server but will shall be looking at how GitHub actions can help us continuously deploy our web app with minimal effort.
What is Continuous Deployment
First of all, what is continuous deployment you ask? According to Search IT operations
Continuous deployment is a strategy for software releases wherein any code commit that passes the automated testing phase is automatically released into the production environment, making changes that are visible to the software's users.
We will not cover tests in this post (but in a later post). As you can see from the definition, simply commit and then all your changes are on the production server.
What is Shared Hosting
There are different hosting choices with the popular ones now being shared hosting and cloud hosting.
A shared web hosting service is a web hosting service where many websites reside on one web server connected to the Internet.
This is the cheapest way to host your website since the different users split the cost of the web server but it also has drawbacks since the resources are split across a number of users as well.
I have been using shared hosting for a long time and I got bored with transferring my files via FTP every time I made changes. I then resorted to using GitHub where I pushed my code to the repo then pulled it from my shared hosting. I still was not satisfied. I used GitFtp which was alright. Until I learned about CI/CD in my Azubi Africa class.
GitHub Actions to the rescue
After further research, came across GitHub actions. According to their site:
Automate, customize, and execute your software development workflows right in your repository with GitHub Actions. You can discover, create, and share actions to perform any job you'd like, including CI/CD, and combine actions in a completely customized workflow.
The Workflow
Let us get to the juicy bit by doing some actual work.
Setting up GitHub actions
(This is assuming you already have a repository in your GitHub account that you want to link to your shared hosting. if not, click here).
Open your repository on GitHub and head over to
Actionstab.
Click on the
set up a workflow yourself →as shown below.
Delete all the contents of main.yml on the page as shown below:
Replace the file with below contents (note this is for a project in Laravel with a Vue frontend)
name: Deploy Site on push
on:
push:
branches:
- master
jobs:
web-deploy:
name: Deploy
runs-on: ubuntu-latest
steps:
- name: Get the latest code
uses: actions/checkout@v2.3.2
- uses: actions/setup-node@master
- name: Installing project dependencies
run: npm install
- name: Building the project
run: npm run production
- name: Copy .env
run: php -r "file_exists('.env') || copy('.env.example', '.env');"
- name: Install Dependencies
run: composer update --ignore-platform-reqs
- name: Generate key
run: php artisan key:generate
- name: Directory Permissions
run: chmod -R 777 storage bootstrap/cache
- name: 📂 Sync files
uses: SamKirkland/FTP-Deploy-Action@4.0.0
with:
server: ${{ secrets.LARAVEL_SITE_SERVER}}
username: ${{ secrets.LARAVEL_SITE_USER}}
password: ${{ secrets.LARAVEL_SITE_PASS}}
Let me now explain block by block what is going on
name: Deploy Site on push
This is the name of the workflow. GitHub displays the names of your workflows on your repository’s actions page after you write it.
on:
push:
branches:
- master
This is where the GitHub action system is told when to run the workflow. The above snippet triggers the workflow when one pushes to the master branch. For more on the On key, click here
jobs:
web-deploy:
name: Deploy
runs-on: ubuntu-latest
jobs - Groups together all the jobs that run in the workflow file.
web-deploy - Defines the name of the web-deploy job stored within the jobs section.
runs-on: ubuntu-latest - Configures the job to run on an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub.
steps:
- name: Get the latest code
uses: actions/checkout@v2.3.2
- uses: actions/setup-node@master
- name: Installing project dependencies
run: npm install
- name: Building the project
run: npm run production
Remember that the steps are inside the job block.
steps - Groups together all the steps that run in the web-deploy job. Each item nested under this section is a separate action or shell command.
name - For identification of the separate action.
uses: actions/checkout@v2.3.2 - The uses keyword tells the job to retrieve v2 of the community action named actions/checkout@v2.3.2. This is an action that checks out your repository and downloads it to the runner, allowing you to run actions against your code (such as testing tools). You must use the checkout action any time your workflow will run against the repository's code or you are using an action defined in the repository.
uses: actions/setup-node@master - This action installs the node software package on the runner, giving you access to the npm command.
run: npm install - The run keyword tells the job to execute a command on the runner. In this case, you are using npm to install the package node dependecies.
run: npm run production - This builds the Vue frontend project.
- name: Copy .env
run: php -r "file_exists('.env') || copy('.env.example', '.env');"
- name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version: '8.0'
- name: Install Dependencies
run: composer update --ignore-platform-reqs
- name: Generate key
run: php artisan key:generate
- name: Directory Permissions
run: chmod -R 777 storage bootstrap/cache
run: php -r "file_exists('.env') || copy('.env.example', '.env'); - This creates a .env file if it does not already exist (this is important as this is automatically added to the .gitignore file).
run: composer update --ignore-platform-reqs - This is used to install and update the composer packages.
run: php artisan key:generate - This generates a key for the Laravel project.
run: chmod -R 777 storage bootstrap/cache - This changes permissions for the specified folder.
- name: 📂 Sync files
uses: SamKirkland/FTP-Deploy-Action@4.0.0
with:
server: ${{ secrets.LARAVEL_SITE_SERVER}}
username: ${{ secrets.LARAVEL_SITE_USER}}
password: ${{ secrets.LARAVEL_SITE_PASS}}
This is where the files are now transferred to the shared hosting server. Get your FTP details from your shared hosting. Then go to your repo>settings>secrets then add the three secrets namely: server, username and then password. This action is courtesy of SamKirkland.
For more information on GitHub actions, click here
Enjoy 😎
Top comments (19)
I have a question... In my shared host the public folder is named public_html but in Laravel is just public... How to set up all files inside public goes to public_html in my shared folder?.... Do I explain well?, sorry for my english btw... hehe
Hi, the way I would propose this is done is that you should have your ftp user point t public_html as the directory. Then all application files will be uploaded there. Then point your domain name to the public folder inside public_html. I hope that makes sense.
Thanks for the tutorial...Let me add that, if you follow this tutorial and your GitHub Action workflow is not running, always make sure that your branch name in the
ymlfile is same with the branch name on your github repo.For example, make sure
mainbranch on your github repo is same with the specified branch inyamland not a different branch name likemasterNice tutorial. However there is a few things I don't understand.
1) why use composer update? I would assume that part would be done locally and any CI/CD stuff would use composer install to ensure that only verified and testet versions are used?
2) why the step with the .env file - as per best practice it won't exists in the repo to begin with and is probably already uploaded to the server (or will be done manually at first deploy)
3) why generate the laravel key each time? wouldn't this be a one time thing at the first deploy? It shouldn't be updated each time?
Hi, thank you for the feedback. I apologize for the late one. Looking and reviewing the tutorial based on your comments got me thinking and you are right on all points. Will update it accordingly. For the .env, it was there as my goal for this whole action was to limit my access to the server thus would want to do everything locally then deploy. The key generation bit is supposed to be at first deploy and subsequent deploys need not have that. I will update it accordingly. Thank you.
My pleasure :)
How is that you first
run: php -r "file_exists, but only thenuses: shivammathur/setup-php@v2? 🤔Does GHA come with "some abstract php" preinstalled, and then you override it with the specific version? Even if so, these two actions should probably be switched, install and then run.
In fact, you are right in the observation. GHA used to come with php 7.4 as default that is why I changed to 8.0 but these should be switched indeed. In fact, now GHA comes with php 8.0 as default so removing the specific version would not hurt. Thanks for pointing it out.
Hi Madalitso!
Thanks for sharing such an informative piece. You know I have completely ditched shared hosting because it comes with so many limitations. As a web developer, I always look to have a lot of choices and flexibility when it comes to hosting providers. I am someone who is managing a lot of clients at a time, so I had to choose the best hosting that offered the choice of having unlimited websites on one platform. I tried out Cloudways managed cloud hosting - 3 day free trial and was mindblown. It is so easy to use and gave me the choice of choosing from 5 hosting providers like AWS, Digitalocean, Vultr, and Linode. It’s been 8 months and I am super satisfied with Cloudways performance, my website’s speed, and the flexibility I get to scale the serve according to my needs. I was also looking for a pay as you go model and thank God Cloudways offers that too.
Great article! Well, I just carried out this process following these steps that you've written so well. Somehow the whole execution took 61 minutes. At the end I found that all the folders have been created on the server but contain no files whatsoever. Very surprising! Any idea why this should happen?
Thanks for the feedback. First, took that long due to the node_modules as well as vendor folders as they have alot of files. Second, after V2 of the FTP deploy action. It only uploads tracked files by default. This link provides a detailed explanation of the issue .github.com/SamKirkland/FTP-Deploy-...
Hopefully that works.
Nice work boss, continue to do a good work
Thanks
Amazing work chief
Thanks boss
@madalitsonyemba thank you for great tutorial, but it seems that I'm missing something...
I tried to do everything like it's described, and workflow works fine, files of initial Laravel App are successfully transferred to the subdomain in the shared hosting.
However, when I try to access my subdomain, application is not running, only files and directories are listed.
From my previous experience of manual deployment of Laravel App to the Shared Hosting there was need to modify and move index.php file to the root directory from /public and modify all paths in asset() functions in project. I've also tried to define Document Root of the subdomain to the /project-dir/pubilc/ on the server and I still just can't run the app, now HTTP 500 ERROR is shown.
I'm not using Vue.js, only basic/initial Laravel App, do you know where is the problem?
Probably late but for the sake of others. I found this as I once have met such before. stackoverflow.com/questions/643334...
Very insightful
Glad to hear that.