Laravel deployment with GitHub Actions

Summary

In this debut YouTube video, Filo, a self-taught developer with 20 years of experience, guides viewers through deploying an application to multiple servers without downtime using GitHub Actions. He begins by creating a new GitHub repository and using Laravel for demonstration, though the method is adaptable to other frameworks. The video covers the steps of setting up GitHub workflows, configuring YAML files, and preparing the application for production. Filo demonstrates creating deployment artifacts, configuring PHP, and managing npm and composer dependencies. The video includes tips on creating a server list JSON file, handling artifacts, and ensuring a seamless deployment across multiple servers. Filo troubleshoots common issues, emphasizing best practices in deployment and server management.

Takeaways

• 😄 Filo, a self-taught developer, shares his journey and expertise through his first YouTube video, focusing on deploying applications without downtime using GitHub Actions.
• 💻 GitHub Actions is introduced as a powerful tool to automate workflows, allowing deployment to multiple servers upon a commit to the master branch.
• 📲 Filo uses a Laravel application for demonstration but emphasizes that the process can be applied to any project, highlighting the versatility of GitHub Actions.
• 🔧 The video tutorial covers the creation of a GitHub repository, setting up a workflow with YAML syntax, and preparing the application for the production environment.
• 🛠 Key steps in the workflow include checking out the code, compiling assets with NPM, configuring PHP, installing Composer dependencies, and creating a deployable artifact.
• 🔍 Filo demonstrates how to dynamically name the deployment artifact using the commit hash for easier identification and manageability of releases.
• 🔒 The process includes securely configuring server information within a JSON file, showcasing how to handle multiple deployment targets within GitHub Actions.
• 🚨 Challenges like password requirements and environment variable configurations are addressed, showing how to troubleshoot and adjust workflows.
• 🔨 Filo navigates through server setup on DigitalOcean, including SSH access and configuring Nginx to point to the correct directory for the deployed application.
• 💡 The script concludes by detailing cleanup processes to maintain server health and demonstrating the deployment across multiple servers, showcasing scalability.

Q & A

What is the purpose of this video?

The purpose of this video is to demonstrate how to deploy a Laravel application to multiple servers without any downtime using GitHub Actions.

What is GitHub Actions, and how does it work in this context?

GitHub Actions is a feature that allows you to trigger workflows when specific GitHub events occur, such as pushing commits to a branch. In this video, it is used to automate the deployment process of a Laravel application to multiple servers.

What are the main steps involved in the deployment process demonstrated in the video?

The main steps include setting up the workflow, creating deployment artifacts, uploading artifacts to servers, extracting archives, running before and after hooks, activating the release by symlink swapping, and cleaning up old releases and artifacts.

How does the video handle the Laravel environment configuration during deployment?

The video creates an environment variable containing the Laravel environment configuration (including database settings, app name, etc.) as a GitHub secret. During deployment, it generates an .env file in the release directory by printing the contents of this secret.

What is the purpose of the 'before' and 'after' hooks in the deployment process?

The 'before' hook allows running commands before the release is activated, such as running database migrations or backups. The 'after' hook allows running commands after the release is activated, such as sending notifications.

How does the video handle shared storage between different releases?

The video creates a shared 'storage' directory outside of the release directories. During deployment, it removes the 'storage' directory from the release and symlinks it to the shared storage directory.

What is the purpose of the 'cleanup' step in the deployment process?

The 'cleanup' step removes old release directories and artifacts directories from the servers, keeping only a limited number of recent releases to conserve disk space.

How does the video handle deploying to multiple servers?

The video uses a deployment matrix configuration, which allows the deployment steps to be executed in parallel on multiple servers defined in a JSON configuration file.

What is the role of the 'symlink swap' technique used in the video?

The 'symlink swap' technique involves creating a symbolic link called 'current' that points to the new release directory. This allows switching to the new release without any downtime by simply updating the symlink.

What additional considerations should be taken into account when deploying to production servers?

The video mentions using repository secrets and SSH keys instead of hardcoding credentials in the configuration file. Additionally, it's recommended to follow best practices for security, monitoring, and error handling in a production environment.

Outlines

00:00

🎬 Introduction and Deploying an Application Using GitHub Actions

The host introduces himself and the topic of deploying an application across multiple servers without downtime using GitHub Actions. He creates a new private GitHub repository and initializes it with a plain Laravel installation. He then explains GitHub Actions and how they can be triggered by specific events like commits to the master branch.

05:02

🔧 Creating Deployment Artifacts

This paragraph covers steps involved in preparing the application for deployment. It includes installing npm dependencies, compiling CSS and JavaScript, configuring PHP version and extensions, installing Composer dependencies, creating a deployment archive with the commit hash as the file name, and uploading the artifact to GitHub.

10:03

☁️ Setting Up Server Configuration

The host creates a JSON file to store server configurations like IP address, username, password, port, hooks for before and after deployment, and server path. He then provisions a new server on DigitalOcean and updates the server configuration file with the server's IP address and password.

15:04

🔑 Exporting Deployment Matrix

This paragraph explains how to export the deployment configuration as a matrix to make it available within the GitHub Actions workflow. It involves creating a new step to read the JSON file, echo its contents with a specific syntax, and store it as an output for later reference.

20:06

💻 Preparing Release on Server

This section covers downloading the deployment artifact from the previous job, uploading it to the configured servers using an action, extracting the archive, creating required directories for the Laravel application, and linking the storage directory to a shared location.

25:07

🏗️ Running Before Hooks and Setting Environment Variables

The host creates a new job to run before hooks defined in the server configuration. It involves setting up environment variables like the release path, active release path, storage path, and base path, making them available on the remote server, and executing commands specified in the before hooks.

30:08

🚀 Activating the Release

This paragraph covers the steps to activate the new release, including symlinking the current directory to the new release, creating and linking the .env file with Laravel environment variables, linking the storage directory, and reloading PHP-FPM if necessary.

35:08

🔄 Running After Hooks

Similar to the before hooks, this section creates a new job to run after hooks defined in the server configuration. These hooks can be used to perform tasks like sending notifications after a successful deployment.

40:09

🧹 Cleaning Up Releases and Artifacts

To prevent disk space issues on the server, this paragraph introduces a cleanup step that removes old releases and artifacts, keeping only the most recent five releases and associated artifacts.

45:09

🎉 Deploying to Multiple Servers

The host demonstrates deploying the Laravel application to multiple servers simultaneously using the configured matrix. He updates the application to display the server name on the welcome page, showcasing the successful deployment across all servers without downtime.

Keywords

💡GitHub Actions

GitHub Actions is a CI/CD (Continuous Integration and Continuous Deployment) platform that allows developers to automate their software development workflows directly within GitHub. In the context of the video, GitHub Actions is used to automate the deployment process of an application to multiple servers without downtime. The script demonstrates how GitHub Actions can trigger workflows based on specific events, such as a push to the master branch, to build the product and upload it to multiple servers, illustrating its utility for seamless, automated deployment.

💡Deployment

Deployment in software development refers to the process of making an application available for use. The video focuses on deploying a Laravel application across multiple servers without any downtime, highlighting the importance of deployment in maintaining the availability and reliability of web applications. The use of GitHub Actions for automated deployment processes is discussed, showcasing how deployment strategies can be automated to ensure consistent and error-free application releases.

💡Laravel

Laravel is a web application framework with expressive, elegant syntax. In the script, a plain Laravel installation serves as the example project for demonstrating the deployment process. This choice illustrates Laravel's popularity and utility as a PHP framework for building modern web applications. The video covers specific steps related to Laravel deployment, such as compiling CSS and JavaScript, and configuring PHP, underscoring the framework's requirements in real-world deployment scenarios.

💡YAML Syntax

YAML Syntax refers to the data serialization format used for writing configuration files, which is both human-readable and machine-processable. In the context of the video, GitHub Actions workflows are defined using YAML syntax, showcasing how deployment workflows are configured. The script provides an example of creating a YAML file to define triggers, jobs, and steps for the deployment process, highlighting YAML's role in specifying the operational details of GitHub Actions workflows.

💡CI/CD

CI/CD stands for Continuous Integration and Continuous Deployment, a set of practices designed to automate the integration of code changes into a shared repository and to ensure that applications are reliably released to production without downtime. The video emphasizes the CI/CD aspect by using GitHub Actions to automate the build and deployment process of a Laravel application to multiple servers, showcasing how CI/CD methodologies can streamline software development workflows.

💡Workflow

In the context of GitHub Actions, a workflow is an automated process that you set up in your GitHub repository to build, test, package, release, or deploy any project on GitHub. The script outlines the creation of a workflow file using YAML syntax to define the deployment process, including jobs like setting up the environment, compiling assets, and uploading the build to servers. This highlights the flexibility and power of GitHub Actions to automate complex software development tasks.

💡Artifact

An artifact is a file or collection of files produced during a workflow run, such as a compiled application, logs, or binary files, which can be stored and retrieved for future use. The video describes the process of creating a deployment artifact (a compressed archive of the application) and uploading it to GitHub for distribution to servers. This demonstrates how artifacts play a crucial role in CI/CD pipelines by enabling the sharing of output between different stages of the deployment process.

💡Zero Downtime Deployment

Zero Downtime Deployment refers to updating applications and services without affecting the availability and access for users. The video's primary focus is demonstrating how to deploy a Laravel application to multiple servers using GitHub Actions without causing any downtime, illustrating strategies like artifact creation and server configuration to ensure the application remains accessible during the deployment process.

💡SSH (Secure Shell)

SSH, or Secure Shell, is a cryptographic network protocol used for secure access to remote servers. In the deployment process described in the video, SSH is used to securely connect to servers, execute commands, and transfer files. This showcases SSH's importance in deploying applications, as it ensures secure communication and operations between the local machine and remote servers.

💡Environment Variables

Environment variables are dynamic values which affect the behavior of running processes on a computer. They are used to manage application configurations separate from application code. The video explains how environment variables, like the commit hash or database passwords, are used within GitHub Actions workflows and SSH commands to dynamically configure the application deployment process. This highlights their utility in customizing and securing the deployment environment.

Highlights

The video demonstrates how to deploy a Laravel application to multiple servers without downtime using GitHub Actions.

It covers setting up a GitHub Actions workflow file, creating deployment artifacts, configuring servers, uploading artifacts to servers, and activating the new release.

The workflow includes steps for installing dependencies, compiling assets, setting up PHP, installing Composer packages, and creating a deployment archive.

It demonstrates how to export server configuration details (IP addresses, credentials, paths, hooks) to the workflow.

The video shows how to upload the deployment archive to servers using an action and extract the contents into a new release directory.

It covers setting up a shared storage directory for Laravel, linking it to the new release, and creating necessary directories.

The workflow includes running before and after hooks, allowing custom commands to be executed on servers before and after the new release is activated.

It demonstrates how to create and link the Laravel environment file with sensitive configuration values from GitHub Secrets.

The video shows how to symlink the new release directory to the 'current' directory, effectively activating the new release.

It includes steps to clean up old release and artifact directories on servers, keeping only the most recent releases.

The video showcases deploying the Laravel application to multiple servers simultaneously using GitHub Actions' parallel execution.

It highlights the importance of using repository secrets and SSH keys for production environments instead of hardcoding sensitive information.

The video emphasizes the benefits of having a single source of truth for environment configuration files instead of scattered files across releases.

It encourages users to follow along with any project, not just Laravel applications, and adjust the steps accordingly.

The video encourages viewers to support the channel by liking and subscribing, and provides an opportunity for viewers to ask questions in the comments section.

Transcripts

hey youtube in this video we're going to

take a look at deploying a layer of

application towards multiple servers

without any downtime using github

actions before we dive in

my name is filo and you're actually

watching my very first youtube video

about which i'm both excited

and also a little bit nervous i'm a

self-taught developer and my journey

started 20 years ago with frontpage

anyone who remembers that kinda makes me

feel old

anyways i've decided to dedicate 2021

towards sharing what i've learned over

the years

learning how to program getting started

as a freelancer but also co-founding a

startup

and the roller coaster that awaits you

when you get your first investment

but let's leave that for future videos

and get started with deploying our

application

towards multiple servers without any

downtime using data

[Music]

action

let's start with a quick introduction to

github actions

github actions allow you to trigger a

workflow when specific github events

occur

for example you can run a test suite

when a pull request is made

or in our case create a build of our

product and upload it to multiple

servers

when the commit is pushed to our master

branch

our first step is to create a new

repository on github

so i'm going to create a new repository

called hello world

i'm going to make it private and i'm

going to create it

okay so in this example i'm going to use

a plain

laravel installation but you can use any

project that you want

whether it's a wordpress website a

static website

it doesn't really matter you can just

follow along and

adjust accordingly

so i'm going to switch over to my

terminal

and i'm going to use the laravel

installer to install

a plain version of the framework

next i'm going to add our data

repository to our

local environment so we can easily push

to get

up when we make changes

now let's add the code that we have so

far

and let's push it up to get up

okay so we have our repository set up

now we can move over to

creating our workflow let's open up our

editor

and let's create our first workflow file

github actions uses a yaml syntax to

define the events jobs and steps

these yaml files are stored in our

repository in a directory called

github slash workflows so let's create

that now

create a new file type dot github

slash workflows you can name your

workflow file

anything you want in this case i'm going

to name it

deploy application.yml like i mentioned

github uses a yaml syntax so we're going

to

first define a name i'm going to call

our workflow

deploy application next we want to

define

the trigger that's going to trigger this

workflow

so i'm going to say on push

and i only want this event to trigger

when a push has been made

on the master branch

next we're going to start with our first

job we basically want to prepare our

application

so that it's ready to be run on the

production environment

in this case we're using laravel so we

want to make sure that we compile our

css

our javascript and install our php

composer dependencies let's start off by

giving an

identifier to a job let's call it create

deployment

artifacts

next we're going to provide it with a

name that's going to be displayed in the

github interface let's call it

create deployment artifacts next we're

going to define our runner

our runner is basically a server that

has the github actions

runner application installed in this

case we're going to make use of a

runner that is hosted by github and

we're going to choose ubuntu

latest now we can continue by defining

the steps that we want to execute

on our runner in this case on the ubuntu

latest environment so we're going to

start off by

importing our repository code by default

it's a

empty os so it's just ubuntu with

no source code whatsoever so in our

first step

we're going to make use of an existing

action

in this case the checkout action which

is provided by github which allows you

to check out your source code

into your runner with just a single line

of code

so now that we have our source code we

can continue by

pulling in our npm dependencies

compile our css and javascript

so start off by giving it a name

and next we're going to use the run

parameter

to define a command that we want to run

inside our

runner which is ubuntu latest

so be using the pipe character you can

enter

multiple lines so in this case we want

to do npm install

and npm run production this will install

our npm dependencies and compile our css

and javascript

let's push the changes that we have so

far up to get up and let's see

what happens

when you switch to get up you'll notice

this orange indicator

this indicator tells you that a workflow

is currently running

so when you click actions you will get

an overview of

all your previous workflows that have

been executed and the ones that are

currently

running and as you can see our workflow

is currently in progress

click it you will get some more

information about the different jobs

which

exist inside this workflow in this case

our

create deployment artifacts with the

power of video editing

i'll make sure that i cut out any

waiting time so you

don't have to wait for every workflow to

be completed

our first workflow has just completed

let's take a look and see what has

happened

here you get an overview of all the

different steps inside

the create deployment artifacts job you

can see that it has

a setup job which is defined by github

and you can see that it's downloading

the required actions that we define in

our workflow

in this case it's calling the checkout

action

you can see that it checked out our

hello world repository

next we got our compile css and

javascript step

and you can see that it downloaded our

npm dependencies

and it successfully compiled our

javascript and css

okay next up want to make sure that our

runner is configured with the correct

version of php in this case we're going

to configure it with

php version 8 and we're going to make

sure that

certain hp extensions are enabled which

are

required by level in this case we're

going to make use of

a community build action this action is

going to help us to configure

php inside our runner with just a few

lines of code

so let's reference the action that we

want to use and let's provide it with

your required input parameters

let's define our version of php which is

8.0

and now let's define the extensions

which we want to include

in this case level requires mb string

c type file info

openssl

video emath

json tokenizer

and xml

let's commit these changes and push them

up to get up and

see if it works switch back to our

actions

and as you can see a new workflow has

been queued

let's forward to the output of our php

configuration

you can see that it found version php8

it set up composer which we need to

install our dependencies

and then enable the extensions which we

defined in our yaml file

so now that we have php configured and

composer installed we can install our

composer dependencies

so let's create a new step and let's

call it install composer dependencies

next we want to run a command inside our

runner

we can do composer install no dev

because we don't want any depth

dependencies on production

we add the no interaction flag because

it's an automated process

and we want to state that we prefer the

distribution source

okay so let's quickly commit these

changes and take a look

again going to speed up this a little

bit in post production

and there you can see our php composer

dependencies have been

installed successfully okay great

our build is complete so now we can

prepare it to be shipped to our

remote server in this case i want to

create an archive

of the entire application so we just

have one file to work with

okay let's name our next step let's call

it create deployment artifact

followed by the command that we want to

run inside a runner

in this case we're going to create a

archive

we're going to use the tar command with

the c flag

to tell it to create a new archive we're

going to use the z flag to tell that we

want to use

g zero compression and we're going to

use the f

flag to define that we want to have the

output

in a file

let's name the file app.gz

now what will happen it will create an

archive from all the files

in our current directory and as you

remember we've

installed npm dependencies that we

actually only needed

to create this build so we want to make

sure that these files are not included

in our archive

we can achieve this by using a exclude

flag

and we can define a pattern that we want

to use

to exclude for example the git directory

or in this case

the node modules directory let's push

these changes up to github and verify

that the results are as

we expect

the job has been completed you can see

that the command has

successfully executed since we're

pushing this file up to our remote

server

the file name app.gz is a little bit

unclear

we're not sure which release is actually

inside

so i want to make sure that we can

identify each release

by naming the file of our archive and

make sure that it's equal to the commit

hash

we can do this by using a get up action

syntax

which is available in these specific

yemo files

so start off by renaming our app

and use a an environment variable that

will be equal to our commit hash

now this environment variable doesn't

exist yet so we need to make sure that

the runner knows what the github

commit hash is

we can achieve this by using the

environment flag

so we're going to tell it that the

environment variable github

sha is equal to the commit hash

if you want to know more about the

available properties that you can

reference

be sure to check out the documentation

on github.com

so let's reference the commit hash and

that's it we can now continue with our

next step which is

uploading our deployment artifact okay

let's define our next step

and we'll start off again by providing

it with a name let's call it

store artifact for distribution

next we're going to use a getup action

again

just like the checkout action github

also has a

specific action which allows you to

upload

build artifacts

we're going to use the uses key to

reference actions

slash upload this action requires a

couple of parameters

so we're going to use with to define

these parameters

we're going to start off by a name this

is going to be the name of our artifact

that we can use for later reference

for example in a future step we want to

download these artifacts

and we need to reference the name that

we define right here

so let's call it app dash build

next we need to tell the upload artifact

action

to tell where we can find our file that

we want to upload

so we're going to reference the archive

file we've created earlier

the commit hash as our file name plus

star.gz

let's commit our changes to git up and

verify that everything works

okay so our workflow is running let me

quickly fast forward to the end of the

job

okay there we go as you can see we now

have one artifact

with the name app built and it's a

little over 3.6

megabyte okay so now we can work on

uploading our artifact to our servers

but at the moment

we don't have any information about our

service just yet

so in this case i want to create a new

json file

which will contain a list of our servers

with the required information

like ip address authentication like

username and password

and a bunch of other configurations so

let's start off by creating a

new file in the root of our repository

called deploymentconfig.json

start by giving our server a name and

it's just for easy reference so when we

take a look at the github ui we can

easily spot it

followed by the ip address of our server

next we got our username let's

enter root let's add a password as well

i'm going to set it to git up actions

for now

next we got our port which is 22 for ssh

i want to be able to set a hook before

and after the deployment on each server

so we're going to add a

before hook option where we can enter

any command that we want to run before

our release is activated

for example we can run a database

migration or

run a database backup you name it

when a release is complete we might want

to send out a

select notification so let's create an

after hook configuration option as well

next we want to set up a server path

which

is where our website will be located so

in this case

i'm using engine x i'm going to point

the directory

to far slash www

html i don't have a server set up just

yet

so let's head over to digitalocean to

quickly configure a server

if you already have a server up running

that's totally fine you can just skip

ahead to the next part

so let's start by creating a new server

i'm going to use a

marketplace image which has linux mysql

and php pre-installed

select the type of server we want to use

i'm going to choose amsterdam for my

region

and i'm going to use password

authentication

for this example but i highly recommend

that you use ssh keys in production

okay so the password that i've entered

earlier in the server configuration does

not meet

the password requirements from the

digital ocean

so let's make this one a bit more

complicated

let's make sure that we also update our

password in our configuration file

okay so let's leave the host name as it

is

and that's it let's create our server

okay let's copy the ip address and let's

see if we can ssh into our server

there we go that seems to work

now let's quickly verify that our server

can be reached

and that our web server is up and

running there we go that seems to be

working as well by the end of this video

we will have achieved the

following directory structure now i want

to point out the

current and releases directories

the releases directory contain the

releases that we upload

these are our unarchived artifacts

when the archiving is done we swap out

the

current directory and point it to the

new release

so the current directory doesn't really

exist it's more like a

shortcut into our release directory

so we need to make sure that our engine

x configuration is pointed to this

current directory

so let's ssh into our server and make a

change to the

engine x server configuration let's

change the

root directory of our web server and

open

the current directory now in our case

we're deploying a laravel application

which comes with a specific public

directory and we need to point our web

server

to that directory so let's append public

as well

let's save our changes and restart nginx

and if you reload the browser then you

can see that the changes have been made

to the nginx configuration

but that it currently cannot find that

directory

let's update our configuration file with

the ip address of our server

in this example we just have one server

that we're going to work with but you

can add as many as you like although

github does has a limit when it comes to

the deployment matrix in which we're

going to talk next

and this has a specific limit of 265.

so if you exceed that limit then you'll

probably have to look at a different

solution

okay so before we can continue we need

to export our configuration file that

contains our servers

and make it available inside our

workflow

in order to do this we need to add an

additional step

let's create a new step and let's name

it export

deployment matrix

and basically what we're going to do is

use the runner

to load the contents of the deployment

configuration file echo it out

to the command line interface and use a

special syntax

so github understands that we want to

make this information available inside

our workflow

since you want to reference the output

of this specific job later

on we want to provide it with an id so

let's name it

export deployment matrix

next we'll define our command

let's create a json variable and assign

it to the contents of our deployment

config.json file

so this doesn't work really well with

multi-line json files

so i found a piece of code which

basically

escapes the multi-line json file that we

have

and make sure that it works so now we're

going to echo out our json

but we're going to prepend it with a

specific name

which allows github to read it

so we can do set output

we're gonna provide it with a name we're

gonna call it

deployment matrix next we're gonna

provide it with the value

in this case our json string okay now we

need to tell github that we want to

store this information so we can use it

for later reference

so scroll back to the top

and add a new input parameter called

outputs to the create deployment

artifact step

provided with a key that we can use for

later reference in this case we're going

to call it

deployment matrix

next we'll use github specific context

information that we've used earlier to

get the git comment hash and now we're

going to reference

steps followed by the id of our step in

this case

export deployment matrix

output followed by the name that we've

provided in the echo statement

which is deployment matrix

okay we're all good to go to move on to

our next job

in this case preparing the release on

our server

so let's name it prepare release on

server

now we're gonna define that this runs on

the latest version of ubuntu as well

next we're gonna use the needs parameter

to make sure that our previous step has

been completed

otherwise they will run asynchronous

and now we're going to work on our

matrix

so we use the strategy input parameter

use the matrix keyword to build a matrix

configuration

you can basically see this as a for each

loop

the steps that we define in this job are

going to be repeated

on the objects with inside the matrix

in this case this is going to be our

server configuration

so we're going to load the json which we

exported in our previous step

into the repair release on server step

okay so the matrix is going to loop

through our json file and we want to

provide a name that we can use to

reference the information in our json

file

in this case we got a list of servers so

let's use the keyword

server the matrix

expects a array to be provided

at the moment we have a json string

so we're going to use the function

called from.json provided with the

output of our previous step

we can do this by referencing of the

chain so we're going to say needs

dot create deployment artifacts dot

outputs

dot deployment matrix which matches up

with the

output variable that we defined earlier

now that we have our matrix setup we can

continue

with setting up the steps for this

specific

job so we want to start out by

downloading the artifact from our

previous step

so again we're going to use a github

specific action

which is called action slash download

artifact so this action

only requires one input parameter which

is the name of our artifact

so let's enter app dash build

let's commit the changes to get up and

take a look

okay so our export deployment matrix

step has failed

let's take a look at our workflow file

to see what's wrong

ah it looks that i forgot a quote

let's try that again

and there you go this time it has

completed successfully

and on the left hand side you can

actually see that it has successfully

read our matrix as you can see that it's

saying prepare release on servers and

you can actually see that it's

referencing

server one with the ip address

again this includes the

credentials as well so in production

make sure that you use

repository secrets and ssh keys

okay so we got our artifact downloaded

next we can upload it to our servers

again we're going to make use of a

community build action

which allows us to upload our zip file

to our servers

first let's create our next step let's

name it upload

followed by the users parameter to

provide the action that we want to use

in this case apple boy

scp action by the way if you want you

can copy and paste the name of your

action

and just head over to github.com the

name of your action

and you actually see the source code of

the action which is being run behind the

scenes

so here you can see these actions allow

for copying files and artifacts via ssh

and on this page you can see the usage

input

variables and code examples on how to

specifically use this

action okay let's head back to phpstorm

and provide the necessary input

parameters

i'm going to start off with the host

which is going to be equal to the server

ip

we've got the server ip in our

deployment config so we only need to

reference it here

we can use the server object inside our

matrix to be defined above

so in this case matrix.server.ip

which will reference the ip address

inside our deployment config

let's repeat this process for the

username

password

or next we're going to define the source

which is going to be the file that we

want to upload

so this is going to be equal to the

commit hash so again we reference github

dot sha we append

the file extension which is dot tar.gz

next we're gonna define the target this

is going to be equal to the directory

where we want to upload the file on a

remote server

so in this case matrix.server.path

to reference the server path that we

define in our deployment configuration

now let's make sure that our artifacts

are grouped nicely together inside a

single directory

so let's append the server path with a

new directory name

called artifacts this will be equal to

far slash www.html

artifacts let's commit our changes and

push them together

let's verify that our action is working

and that our artifact is uploaded to our

server

let's fast forward to the end of this

workflow

there we go it successfully executed the

transfer

to our server let's ssh into our server

and verify that the file's there so i'm

going to check

inside our var slash www

html directory to see if our file's

there

it looks like something went wrong

because we only got our index.html

so let's take a look and it seems that

i've got a w

inside the server configuration where we

define our server path

let's commit the changes and try this

again

the workflow has successfully completed

the upload has been completed

and it looks like that it created the

folder in the correct place

so let's check our server and there we

go our artifacts directory is there

and it does contain our archive with our

current release

okay so we got our file on our server

now we need to extract it

so that we have a release to actually

work with

so let's create a new step let's name it

extract archive and create directories

so in order to extract our archive we

need to ssh into our remote server

we're going to use a another action by

the same author

called appleboy slash ssh action

which will allow us to execute remote

commands

on our server i'm going to copy and

paste the hostname username password

import

since those are exactly the same as in

our previous step

next we'll use the script input

parameter to define the commands that we

want to run on a remote server

let's kick off by creating a new

directory that will hold

our current release let's use the make

their command

to create the directory if it doesn't

exist yet let's reference our

server path followed by the releases

directory

followed by the commit hash now this

github underscore sha environment

variable doesn't exist yet

so let's make sure that we pass it

inside our

input parameters for this specific

action so let's set the n

flag and let's define github underscore

sha

to be equal to the commit hash of this

release

environment variable will now be

available inside our runner

we want to make sure that it's also

available for us inside

our remote server

we can do this by providing a

environment input variable

for our action so now this environment

firewall should be available on a remote

server

let's extract the contents of our

archive into the release directory we

just created

we can use the tar command to extract

our archive

so let's do tar x z f

followed by the path to our archive file

which is equal to

our server path followed by the

artifacts directory

followed by the mid hedge of our current

release

and of course the file extension which

is dottar.gc

next we'll add the c flag

to make sure that the tar command

understands that we want to extract

contents

into the releases directory which again

is our server path followed by slash

releases

slash our release commit hash

time to commit our changes again and

push them up to get up to verify that

everything works

let's fast forward again to the output

of our workflow

okay it seems that our job has filled so

let's take a look what's going on

cannot find our archive and it seems

that the name is incorrect because those

brackets shouldn't be in there so let's

take a look at our workflow

and there you go i made a mistake right

there the dollar sign

should be before the bracket so let's

change it

let's push the changes to get up and

let's try again

this time the job has successfully

completed so let's ssh into a remote

server

check the release directory and make

sure that our files are there

and there we go our laravel application

has been extracted

into the release directory let's head

back to phpstorm and continue with our

workflow

we're going to make some specific

changes for our larva application

if you don't use level you can still

follow along we're going to work on

something which allows us to share

storage between different releases if

you're unfamiliar with laravel

basically it ships with a storage

directory inside our repository this

directory is somewhat empty

but on our production release we might

actually have files in there

and of course we don't want to overwrite

our files on our server

so let's make sure that the storage

directory is removed from

our release so we can link it up to our

shared storage directory so we use

the rm command to remove this directory

which is located in our server path

followed by

our releases directory our release

commit hash followed by the name of the

directory which is storage next we'll

replicate the storage directory

structure

but outside of our release and again

using the make their command to make a

storage directory inside the storage

directory we're going to

create a couple of new folders which are

required for the laravel framework in

order to

function in this case app

public framework

and logs our framework directory

requires a couple of

extra directories let's make sure these

directories exist as well

in this case cache sessions testing

and views finally we need to make sure

that the storage directory

and all sub-directories are writable

so let's make sure that we provide the

path to our storage directory

and continue with our next show so in

our next step we are going to run our

before hooks

which allows to execute any commands

before our release is activated

let's identify our next job by calling

it run

before hooks

and of course let's give it a name as

well if you want to make your steps

easier to read you can actually

reference your matrix object within the

name

as well so for example we could do

matrix server.name to get the name of

the server

and add beforehook so in the github ui

we'll get

server one beforehand which makes it

easier to identify on which server

the actual job is running we're gonna

repeat a couple of things of course

again we're gonna make sure that it's

running on the latest version of ubuntu

we're gonna define our needs parameter

to

tell it that we want to have our create

deployment artifacts and our prepare

release on server

jobs to be completed we're going to

reference our

matrix again and let's just copy and

paste it from our previous step

let's name our step run before hooks

let's save ourselves some time by

copying the step from our previous job

to execute a command on a remote server

next we'll add the script tag again

followed by the before hook from

our server configuration by referencing

our matrix objects so let's do

matrix.server.for hooks

inside our server configuration we can

now define our beforehooks

these beforeholds will be executed

before we activate release

so you might like go into a certain

directory and execute a clone

it would be pretty nice if we don't have

to do things like

far slash www etc

but we can reference a environment

variable which makes it a bit easier for

us for example

we could do c d release path in order to

get in our current release directory

this won't work just yet

we need to make sure that the

environment variable actually exists so

let's define our environment variable

which we called release underscore path

we'll reference the server path followed

by the releases directory

followed by the directory name which is

equal to our release commit hash

okay next we want to set an environment

variable that we can use to reference

the path to our active release

so let's name this environment variable

active underscore

release underscore buff followed again

by the server path

followed by the current directory

next we also have a storage path which

is the path to our storage directory

and the base path which is nothing else

than our

server path now let's make sure that

these environment variables are actually

available on a remote server by again

going to the

input variables for our ssh action

and defining the ends input variable

followed by

the environment variables that we want

to make available in this case our

release hash

our release path our active release path

our storage path

and our base path now we of course want

to make sure that this actually works so

let's head over to our deployment

configuration

and echo out the github commit hash

time to push our change up to get up and

take a look it seems something went

wrong

the workflow is not valid job run

beforehand depends on unknown job

prepare release on server

so let's take a look and it seems i've

got an

s right there let's try again

this time our workflow has successfully

completed let's verify that our commands

are successfully executed

that looks good let's verify on our

server and our storage directory is

there and you can see by the green

highlight that

the write permission is set correctly

next we got our before hook let's open

it up and there you can see

we echoed out the github commit hash and

on line 30 you can see that it is equal

to 884 etc so that is working as well

our environment variable is available on

a remote server now it's time to work on

the most exciting step

activating our release let's just copy

paste to run before hook step since the

active release app is

going to be a couple of ssh commands as

well

let's rename it to activate release

of course make sure that our run before

hooks has actually completed before we

run this job

change name to activate release as well

let's change the step name okay i think

i spot a mistake that i made in the

previous

job and there should actually be a

single dollar sign

instead of two so let's make sure that

we update this across the file

i think we got them all let's replace it

with a single dollar sign

and two brackets

okay so now we want to make sure that

our current directory is pointing to

our new release we can do this by sim

linking

we're gonna simulate the current

directory

to the directory that holds the current

release

we'll use the ln command to set up a

symbolic link

the s-flag means it's a symbolic link

the n flag tells it that it's just

treated

as a normal file or directory and

dash f tells it to force or overwrite a

link if it already exists

this is then followed by the path to our

new release

and we want to make sure that it's

linked up to our slash current directory

or as we referenced before as the

environment variable

active and the score release and square

path in case you are using

engine x with php fpm you need to make

sure that php is actually reloaded

otherwise it will not pick up the

changes when we swap out a symbolic link

so we'll do this by doing surface hpa

fpm

reload time to verify that everything

works so let's push this up to get up

and take a look

at our job in this case it has

successfully executed commands on our

server it has set up the link

and it has reloaded php8 let's verify

this on our remote server

and there we go as you can see our

current directory is currently

simulink to the release that we just

deployed

let's see the interrupt current

directory to verify that our application

is of course actually there and there

you go

if you would head over to our browser

you can see that it isn't working just

yet

this is because we still need to set up

a couple of things in order for this

level application

to run successfully if you're unfamiliar

with laravel

it ships with a environment

configuration file

this file basically contains things like

the application name the url

database settings etc etc this file

needs to exist and needs to have a

couple of configuration options defined

in order for our framework to work

let's kick off by creating a environment

variable that's called laravel and score

n

and let's make sure that equals to the

level and secret

secret again is a keyword that is

context specific to this creative action

and we can define our secrets within the

github ui

so head over to your repository go to

settings secrets

new secret let's enter the same name

that we defined in our workflow file

which is laravel and screen

and i'm just going to copy and paste in

a example environment file that ships

with laravel and i just

changed the app name and the environment

to production now during each deployment

we want to make sure that our

environment file is updated

it doesn't exist right now so let's make

sure that it does

we will use the printf command to echo

the contents of our secret

into our environment file which is going

to be located

in our base path

of slash.nfc this file needs to be

inside our release

so we're going to use the link command

again but this time we're going to link

the environment file

from our base path to our release path

i could argue why not create this

environment file inside the release

directory well that will result in a lot

of environment files

scattered across all our different

releases i prefer to have a single file

which is a single source of truth

this makes it easier to work with since

we're here let's link up the storage

directory as well

we'll use the ln command and reference

the storage path

followed by the release path which

basically means that we now have a

storage directory available in a release

which is simulink to the storage

directory inside our base path

let's trigger the workflow and verify

the results on our server

okay everything has successfully

completed

let's take a look at our website and

unfortunately

it seems that it's still not working

let's go back to our server and take a

look

our files are there the end files is

there it's correctly linked

current directory is there

but the environment file is empty

let's see our level and is defined

i've got to pass the environment

variable to our remote server

so let's give this another try

okay our workflow has successfully

completed

but it's still not working

let's verify that there are environment

files there

okay that seems to work

but it's not yet working okay i quickly

paused the video for a second

i forgot to update my engine x

configuration

this server is proficient with php 7.4

which i upgraded to

version 8 but i've got to update the

engine x configuration

that was still referencing to php 7.4

so let's change it reload nginx and try

again

and yet it's still not working

let's dive back into the server and

check the error log

so larval is complaining about the fact

that we provide a

envelope cache path so

it seems that i forgot to create a

additional directory inside our storage

framework

cache directory which is a data

directory

so let's quickly create this right here

make sure that it has correct file

permissions

and refresh and there you go we have

successfully deployed

our laravel application so we've

manually

fixed it on our server but of course you

want to make sure that it is fixed in

our workflow as well

so let's head over back to phpstorm

scroll up and let's make sure that the

data directory

is created inside the cache directory

let's copy and paste our previous

command and let's adjust it accordingly

and next up we got our after hook

so to make things a bit easier let's

just copy and paste our before hook

since it's

almost the same

let's make sure that our activates

release job has finished before we

triggered the after hook

by adding it to our nice array

next we'll update the identifier to run

after hook

we update the name as well and the name

of the step

and finally let's make sure that we

reference the after hooks from our

server configuration

okay great our after hook is done as

well let's continue with a little bit of

a cleanup

every time this workflow is triggered it

will upload our artifacts

now if you do this 100 times this will

mean you have 100 artifacts

and these artifacts take up disk space

and you probably don't want to end up

with your server crashing in the middle

tonight because

it has run out of disk space so let's

make sure that we

clean up the releases and artifacts

directory

let's copy and paste our run after hook

shop and let's make some changes

let's change the identifier to cleanup

update the

name accordingly and the step name as

well

of course make sure that our after hook

has completed before we are running the

clean up

we don't need the environment variables

that we created earlier so let's remove

them

and replace them with two new

environment variables

we want one environment variable to

reference our

releases directory and another

environment variable that

references our artifacts directory

now we need to make sure that these two

environment variables are passed to a

remote server so

update the ends input variable of our

ssh action

let's cd into our releases directory and

list all the releases by time and date

next we'll use the till command to

offset this list by 5

and return any remaining directories

that might exist

we'll use remove command to remove any

directories that are returned by the

tail command

now we want to replicate this behavior

for our artifacts directory as well so

let's copy

and paste this line and update the

environment variable to reference

our artifacts path time to commit this

to git up and

trigger workflow to verify if this works

let's fast forward again to the output

of our workflow so

our commands have been successfully

executed on a remote server so let's

verify this by

let's verify this by listing our

releases and of course

our artifacts as well as you can see

there are five remaining of each

and all the additional files have been

removed

that's it we've successfully deployed

our laravel application

to a remote server without any downtime

in this video we've used a single server

when we deploy our application

i've duplicated the server that we've

been using three times so we have a

total of four

and i've updated our server

configuration to include these

additional servers

by default github actions run in

parallel

which is quite nice as you can see right

here it's executing the prepare release

job

on all our servers simultaneously

to see this in action i've also updated

our level application

to include the server name on the

welcome page so if we take a look you

can see that the documentation title has

uploaded to server 1

server 3 server 2

and server 4. i hope you enjoyed this

video and

if you'd like to see more of these be

sure to support me by clicking the like

button

and subscribing to my channel i truly

appreciate all the support

oh by the way if you have any questions

drop your comment below and i'll get

back to you