By Benjamin Eberlei, first published at Fri, 28 Feb 2014 12:12:20 +0100
Download our free e-book "Crafting Quality Software" with a selection of the finest blog posts as PDF or EPub.
You can also buy a printed version of the book on Amazon or on epubli.
The amount of time wasted on setup, synchronization and deployment of applications is often ignored by teams and managers. Manual server management and application deployment are a huge waste of time and ultimately money. In addition, manually performing these tasks is often prone to error and a big risk for uninterrupted uptime of production.
Software quality does not stop with tests and good CodeSniffer and PHP Mess Detector scores. The deployment and setup is equally important to the quality of an application. From our experience, this is a field where many teams could still achieve huge productivity gains.
As a yardstick for the optimal solution, we can take a look at what the Joel test has to say about deployment and infrastructure and add some of our own additional requirements (some from the OpsReportCard):
Can you make a build in one step?
Do you make daily builds?
Do you use configuration management tools to automate infrastructure?
Is the development setup documented and automated?
Can you rollout and rollback deployments in one step?
Can applications be deployed to a new server setup without changes to the code?
I want to discuss these bullets in short paragraphs and mention why solving these problems allows you to save time and money, if done properly.
One of the Joel test requirements is building an application in one step. In the PHP world that means that - by executing one command or pushing a button in the CI system - a process is triggered that creates a running version of your project.
What does a complete build include?
Code deployment to the appropriate machines
Configuration
Database setup or migrations
Service location
Cache Warming
Tools to automate code deplyoment include Bashscript + rsync + symlinks, Capistrano (with Capifony plugin for Symfony), Ansible or Ant. It is perfectly fine to automate with bash scripts, some automation is always better than none. However, the amount of boilerplate with Bash is often quite big compared to the other solutions that explicitly handle most of the deployment issues already. For example, we regularly implement a combination of Ansible and Ant deployment for our customers.
For database migrations there are tools such as DBDeploy, Liquibase or FlywayDB. These can normally be integrated and automated during deployment via Capistrano, Ansible or Ant. This requires the database schema to be always backwards compatible, something to carefully watch out for.
A compelling argument for introducing a reliable one-step build is that it can be safely triggered by any member of the team and therefore reduces the possibility of errors drastically.
If you don't have a one-step deployment, it is very unlikely that you are able to make daily builds in a cost-effective way. Without daily builds you lose one benefit of PHP, the rapid pace of development.
You lose money because you might be slower with new features than your comptetitor or because you cannot remove costly bugs from your software fast enough.
When running many different projects, all with their own unique server setup, you can easily see how this will cost you time and money to maintain all these servers. Automating server maintenance helps a lot.
CFengine was the first tool that automated the setup of servers and it was released in 1993. Competitors such as Puppet, Chef and Ansible are much younger, but still old enough to be considered stable and frankly there is no excuse not to use them anymore.
Configuration management tools all solve the problem of consistenly automating the setup of new and old servers. The goal is to set up all servers in a similar, consistent way by the use of automation instead of manual SSH'ing, package and configuration management.
Tasks you want to automate with configuration management:
Deployment of SSH authorized keys
Security updates of packages
Management of log files (logrotate, fetching, aggregating)
PHP, Apache/Nginx, MySQL, NoSQL, … configuration
Updates of commonly used software such as Wordpress, TYPO3, Drupal, Shopware, Oxid and their third party extensions.
Recently we recommend using Ansible to our customers, because it is so much easier to understand than other tools.
Puppet is much more complex to understand initially from our own experience and also has a much higher learning curve.
There are two obvious reasons why not automating the setup of development machine is dangerous:
Bugs and problems of the category "it works on my machine" are much more likely to happen, especially when development and production machines significantly differ (PHP 5.2 vs 5.3 was such a difference).
You cannot easily introduce new developers to new projects because it always requires a huge amount of time. This contributes to knowledge silos and significantly increases the bus factor of projects.
At a time where php applications use much more services than just the LAMP stack, it is vital that every developer has the same production-like environment to develop on. This can be achieved with virtual machines and tools like Vagrant. Combined with configuration management tools like Puppet, Chef or Ansible, the tools for easy setup of development machines exist and are stable.
A more detailed post from us on Vagrant will be forthcoming in the next weeks.
Nothing always works and for deployments of applications this is even more true. Not accounting for failure is carless. Failure during deployments is not a black swan event, it's real and probably in the >1% likelihood.
You can reduce the cost of failure by being able to rollback to an old, working version.
You need a deployment system where several versions of your code are available on the production machines and where you can switch between them with a single atomic operation. This also requires asset compilation and database schema migrations that are backwards and forwards compatible.
One common mistake in application development is hardcoding configuration variables. Especially in the early development of greenfield projects, too much configuration got hardcoded into the code. The side effect of this is that you will probably lose a lot of time once the first real production setup should be deployed. Hardcoded configuration variables also often complicate the installation of the application on different servers. For continous integration, staging machines or for multiple tenant setups, however, this is extremly important.
Not properly taking care of application configuration will make deployment much harder.
Not automating deployment and infrastructure is expensive and can cause frequent human errors. This article highlighted several deployment problems and discussed tools and procedures to fix them. In the next years, the question of infrastructure automation will become even more important, as automation has positive effects on time to market and allows scaling development teams up. As usual, companies that don't automate will have a hard time competing with companies that do.
If you need help automating your infrastructure and deployment, don't hesitate to contact us. We can help you with the details and problems that commonly occur and we will make sure you get started very quickly.
Stay up to date with regular new technological insights by subscribing to our newsletter. We will send you articles to improve your developments skills.
Navigator on Thu, 01 Feb 2018 07:12:04 +0100
This is a great article on Why we need infrastructure and deployment automation?Thanks for sharing.
Link to commentessay star writers on Mon, 05 Mar 2018 16:56:01 +0100
Must say that it is something everyone experiences. Such things are always very common. Thank you for the good news.
Link to comment