Who automatizes the automatizer?
Integration tests / system tests
Automatic tests — are the bests!
Better than the rests!
Design a control API
Start and stop the system using the API
Self-contained tests: clean-up
Three basic rules:
Make your systems easy to test
Create test script
Everything is coming together nicely
Between Development and Production
Also called: preproduction, replica, build env
Enough data to run all tests
Populated with a script
Store unit and integration tests
Run the whole suite with every change
Check if something has broken
For any new error, introduce a new test
Close the gap between development and tests
Safety net for developers
Notice errors when the code is fresh
Shorten development cycles!
(CD > CI)
Various proprietary dumpster fires
Create integration server
Create integration script
Run integration script
Add Webhook to GitHub
Add tests to deployment
Amateurs talk about programming
Professionals care about deployment
Put your code into production
Different servers, different rules
sudo service [name] restart
Do the manual way...
Or do the cool way: with code
DevOps for the win!
Three basic rules:
Make your systems easy to deploy
Too much of a good thing?
Shorten deployment cycles
Don't let changes accumulate
Stability increases (paradoxically?)
Practice makes perfect!
Run all test suites
A small but essential addition:
git pull npm install npm test sudo service [name] restart
Create a production server
Create script to deploy on production
Add deployment to production
(only if tests work)
Test that it works
One deployment, many servers
Production: listen to signal
Integration: send signals
Get from your cloud provider?
Use AWS/gcloud/Azure API
Integration finds all servers
Notify all production servers
Access AWS to get list of servers
Connect to all of them and update
Modify integration server
Run distributed deployment
Let alarms, alerts and warnings come to you
Every alarm must have:
Make your systems easy to monitor
Send a notification if deployment fails