Starting right now until 5pm on this Monday (27th November) at 5pm you can get a yearly membership to CodeReviewVideos.com for just $99.
This is a saving of over $150 on the usual price.
As of this morning there are 500 videos covering Symfony, React, Docker, and a whole bunch more. There’s 63 courses to check out.
And those figures grow every week.
This is the only offer I will be running this year. Make sure you take full advantage.
Video Update
This week saw three new videos added to the site:
#1 – Part 1/3 – Deploying with rsync
Probably the easiest way to get code from your desktop to your production server is to use a tool like rsync or scp .
We’re going with rsync as if you’re copying up largely the same contents multiple times (as we are in this approach) then rsync will only transfer up the differences on second and subsequent runs. Secure copy (scp ) on the other hand would copy across every file, every time.
This deployment approach is super simple:
Copy stuff from our development directory right into the live / production website directory.
It’s simple and it works.
But it also breaks everything whilst a deployment is in progress, and rolling back is not easy.
We’ve got to start somewhere thought, right?
#2 – Part 2/3 – Deploying with rsync – Using builds
In the previous video we learned the fundamentals of how to shift our data from point A to point B.
There are at least two major problems with this approach:
- We copy everything into the Live / production directory, breaking stuff as we go
- Rolling back is a total pain
Fortunately with just a small tweak to our process, we can improve things greatly.
We’re going to bring the concept of a builds directory into play, and instead of copying up from our PC to the Live website directory, we will instead copy into a sub-directory of builds , such as builds/20171124-0921 .
If we did another deploy a short while later, we could copy up to e.g. builds/20171124-1015
What we then set up is a symlink, or short cut.
We tell Apache or nginx to serve from the shortcut, and then swap out what the shortcut points at, in order to make a different build live.
This solves both of the two problems above, but unfortunately, we lose the benefit of using rsync as each new build is effectively a full copy up of new files.
Still, that’s a minor gripe considering the improvements.
#3 – Part 3/3 – Deploying with rsync – Shared var
There is one remaining problem:
Everyone who is logged in gets forcefully logged out on each new deploy.
Why is this?
Well, each new deploy brings in a new var directory. The var directory contains the sessions directory. If every new deploy creates a new sessions directory then every existing session is going to be lost.
This is a lot less of an issue with stateless authentication.
The fix to this is straightforward:
Share the var directory between every deploy.
To accomplish this we will make use of symlinks once again.
The cool thing about learning all of this is that this is almost exactly how automated deployment tools such as Deployer do this. By learning how to do things by hand, you’re going to find understanding the automated tools much easier.
One thing that automated tools do bring for us is in automating housekeeping chores:
- deleting old builds
- sorting out symlinks
- making long winded commands into one liners
And that sort of thing.
As far as manually deploying with rsync goes, we’re about done.
This process could do to be a lot more robust, but in truth, I don’t recommend hand-cranking a deploy anyway. All we’re really doing here is learning and building a foundation for understanding automated tools, which I would strongly recommend you use instead.
Even so, we’re going to continue looking at another manual approach in the next few videos, this time learning how to Deploy with Git.
Ok, that’s it from me this week.
Don’t forget: the Black Friday Offer expires at 5pm GMT on Monday 27th November.
Have a great weekend, and happy coding.
Chris
