We use Continuous Integration and Continuous Deployment to strategically administer partial changes to complex digital infrastructures. The result of employing CI / CD, is that common mistakes and errors are avoided when making relaunches to production environments. Why is this important? Well, it alleviates the associated risk off the shoulders of our customers, and leaves them free to focus on improvements.
Our DevOps convert and resident admin Stefan, remembers the agonies of digital deployment, looong before there were DevOps workflows and best practices. Attention, nerd talk inbound! Button up for a byte sized stream, from the brain of a 2012 administrator.
It’s the first Tuesday of the month, and it’s deployment day.
As planned, the clock strikes twelve and the store is placed into maintenance mode for the relaunch.
Instead of their favourite products, store customers are greeted by the following message: “Dear Customer! Our store is currently being updated. Please check back in 30 minutes.”.
Nothing out of the ordinary so far; who’s shopping on their lunch break anyway.
A “generous” maintenance window of (clear your throat), one hour is set. After all, only a single zip file has to be unpacked for the update! So far, so good.
Moving on, we download the zip file from the SharePoint server. Luckily, the update is only 500 MB in size, I say luckily because, well, they keep getting bigger each time!?
Maybe we ought to make a backup first:
:~$ mv webroot webroot-bak Error! webroot-bak already exists.
:~$ mv webroot webroot-bakk
Now to unzip the archive:
:~$ unzip deployment-package.zip Error! unzip not found.
Looks like we have to install a dependency:
:~$ apt install unzip
Alright, let’s try that again:
:~$ unzip deployment-package.zip 4000 files successfully unzipped.
Meanwhile it’s 12:36. Alas, the disk I/O could be better, but what do you expect from 4000 PHP files?
Let’s move onto the database migration:
:~$ php bin/console db:migrate Progress: [3% ###------------------]
At this point, a well trained administrator would lumber casually to the kitchen and grab him/herself a coffee.
13:03 – 7043 items get dropped from the database because of stale image links. Looks like we’ve got this one in the bag, let’s disable maintenance mode.
Then the realization sets in, what about the images themselves. Panic ensues… We forgot to copy the images over from the backup!
Wait, what about that coffee, let’s take a sip. Ah, much better.
Let’s hope that the database backups can be restored…
:~$ ssh backup.server.com :~$ bconsole bconsole :~$ restore --server=5 --days=28 bconsole :~$ cd /var/backups/db/dumps bconsole :~$ ls bconsole :~$ add dump.sql.gz bconsole :~$ done Proceed y/n: bconsole :~$ y bconsole :~$ exit
In the meantime, let’s copy those images over:
:~$ mv webroot-bak/public/img/* webroot/public/img/ Error! webroot-bak/public/img/ not found.
Oh, right. That’s an old backup…
:~$ mv webroot-bakk/public/img/* webroot/public/img/
13:21 – Done. How’s the backup doing? 82% – Can’t take much longer.
13:29 – Done. 2 GB database zipped, that’s probably 20 GB unzipped then.
Let’s restore it to the database:
:~$ zcat dump.sql.gz | mysql db Permission denied.
So, where’s that database password again? Thinking heavily. Of course, in the password manager, though it’s not supported on Linux – let’s start a Windows Virtual Machine.
Please do not switch off the computer... Windows updates in progress.
Who would’ve guessed, perfect timing. Guess we’ll have to wait then…
13:48 – Done. Start password manager. Search for MySQL root password for the store. Notes: “root has no password, just use socket auth or debian-sys-maint”.
:~$ zcat dump.sql.gz | mysql --defaults-file=/etc/mysql/debian.cnf db
15:23 – Done. So, let’s run the database migration again:
:~$ php bin/console db:migrate
15:31 – Done. Let’s call up the page. Oops, something went wrong.
:~$ chown –R www-data: webroot
Reload the page.
500 Internal Server Error
Well, the log files don’t show anything useful. Let’s Skype the head developer.
“Will check tomorrow, gotta go now. Dog gets vaccinated”
I guess we’ll have to figure this out then, let’s start by re-importing the database backup again.
16:52 – Done.
Four hours later and no further, we’re back at square one.
Poor Stefan. Thank God the future has finally arrived. Today, he is working for our customers with the help of modern deployment solutions – so that his 2012 nightmare never, ever repeats itself.
With the help of Continuous Integration and Continuous Delivery, our team is able to design a cost-optimized solution, with an individual infrastructure that complies to your specifications. This enables a greater level of flexibility for development teams to modify small parts of the code and, ideally, test them automatically.
Our role in this?
We offer a competitive advantage: On the one hand, your product is always up-to-date with the use of CI and CD. In addition, the time-to-market of new features is significantly reduced, while enabling developers to resolve bugs and security holes with ease.
We’ll put together the necessary infrastructure according to your wishes, specifications and needs in a cost-efficient way. We ensure the smooth-running of the systems and provide support for new developers. To begin, commission the one-time setup as part of your existing maintenance contract and let’s talk about your status quo.
CI / CD / DevOps in a nutshell:
Advantages of CI / CD for developers:
- Code changes are easier to track. e.g. errors can be detected quickly; the management of code becomes clearer
- Developers can concentrate on writing code with a lesser emphasis on deployment
- Deployments are automated
- No loose ends due to lengthy release procedures
- Less manual code review
Advantages of CI / CD for our customers:
- Get your product up-to-date fast and efficiently
- New features are quicker to the market (competitive advantage)
- Bugs and security holes can be faster resolved
Want to switch to DevOps, Continuous Integration and Continuous Deployment?
Great! Contact us now, to discuss the status of your project.