Deployment part 1
to make this work ...
Helpers are a dime a dozen - but why is that? Isn't it actually quite simple?
What is essentially required:
To get a TYPO3 website from the local development to the server, various steps are necessary. I'll try to structure this a little here.
- First we get the current sources from git
- Then we should build our dynamic asset. Tools such as gulp, webpack, grunt or t3-build are usually used here
- Then we install the TYPO3 system using composer
- If you have not solved the problem with settings.php, additional,php and .env well(here is a suggestion), you now have to push this data around so that the system works in the current environment
- The current database may need to be adjusted again
- Now the current translations can be installed again
- Clear cache, start warmup
- Finished
As this whole process can take several minutes, it is not advisable to simply switch off the current live site and then start the new one.
To do this in the background, there are tools such as deployer or surf. (and others). But in the end, these are all just wrappers that call other scripts and if there are some things I don't need, they are programs that run programs.
What you (I) want to have:
Roughly speaking, I would like to push my current development into the stage-branch and then the deployment works by itself. When I'm happy with my new feature, I want to push it to the production branch. But before this goes live, I want to check this build again on the live server. Then I want to make a controlled release with one click.
How does that work? What do I need for this?
To prevent the live site from crashing, we need to carry out the steps from above somewhere offside and only switch over when everything is ready. This is also known as Blue Green Deployment.
As I don't want to install anything on the web server that isn't directly needed to run the website, neither node nor composer can be found on the system I manage. This reduces the number of dependencies and the list of potential points of attack.
I also want the developers to not need server access for deployment.
So, in addition to a local development environment and a web server, I need a build system.
In practice, I use the pipeline system from gitlab and build the complete website in a gitlab runner. Then I use rsync to copy the artifact to a new directory on the web server. When the warmup is finished, I change the document-root of the web server and my new version is online without interruption.
To be on the safe side, the last step is carried out manually. This step can also be controlled via gitlab.
Blue Green Deployment
In order to install the new system on the server in peace, we also need a corresponding directory structure there.
A new release is stored under the current timestamp. The link next is then moved to it.
The systems I manage with this system usually have 3 different URLs:
- stage.michaelstein-itb.de
New features can be tested here - next.michaelstein-itb.de
The current release is tested here immediately before the go-live - current.michaelstein-itd.de or www.michaelstein-itb.de
The live system
Disk space Attention!
To avoid copying a complete fileadmin for each release, this is realized via a link.
This is much faster and saves disk space.
The settings point to the same file per instance, which is located exclusively on the server.
Additional credentials are stored in an .env file in the document root.
As it may be necessary to adjust values in the .env before the release is made from next to current, this file is not linked but is copied by script with each release.
Comments
No Comments