Divante is developing software using Agile techniques. We believe in fast delivery and continuous improvements. Most software companies start focusing on software quality – code quality and features. They hire developers and product implementations. Thinking about post-development or development-process related optimizations like safe deployments and more processive approach are symptoms of company maturity I think. That we had in Divante :-)
A few years ago our deployment process was – let’s say – non-standardized. People made code, we of course use SubVersion (and then GIT) for source control, Redmine for change tracking. But when it came to deploying software on servers – all was the handjob. Full of potential mistakes and issues. IT department (guys in charge of servers and network) works with SD (Software Development) department to manage new version of the software. It could take hours and always was a some kind of holiday :-)
We offer our clients a SLA agreements in standard. Percentage availbility and reaction times are very high in some cases. In this situation deployments are very important piece of the puzzles of high avaibility. When done wrong – it could stop – in our case e-Shop – from making money to our clients. We’re in charge of our clients business so a few years ago we decided to choose more reliable and processive approach using DevOps.
DevOps is an approach to operations on software – like environment setting, automation of processes, deployments. You could read more on that on Wikipedia.
In short words – DevOps is an agile way to maintain software. It emphasizes communication between IT and SD, uses continuous integration techniques and emphasizes the role of multidisciplinary teams – without strict divides between administrators and developers.
For implementing DevOps (in our case) two most important factors played role:
- need of strict deployment process – described as GIT branching scenarios (we use single branching model – You could read more about pros and cons of this way on Netguru blog), Redmine usage and communication
- automation framework – tool for preparing servers and deploying software with even sophisticated configuration
Divante now is managing about 35 software projects which are we developing (time material approach and maintenance). We also maintain about 50 servers (we use virtualization and cloud computing to provide hosting services to our customers). On this scale, each of the two factors was key to success.
We created a simple procedure of deploys:
- features are planned in Redmine using Roadmap to plan each sprint (we use SCRUM),
- we have one-two week-long sprints and we’ve decided to deploy after each sprint,
- we use dev, testing, stage and production environments
- we use GIT (with Gitlab) to manage source code – and deployments rely in 100% on GIT branching model
- we do cross-team code review (using Gitlab; before – PHPabricator but it was inefficient in large projects)
- we use QA team to test features on test and staging and they give us green light to deploy.
A good thing to have is the checklist on that!
After short training, each developer has to pass a “Deployment Exam” which gives him the ability to process deployments. Without certificate, nobody could even login on production servers :)
The procedure is one end of the problem – the second was an appropriate tool for managing configuration, servers and create a bridge between IT and SD. We were thinking about Puppet, Chef, Capistrano. All those tools were mature – started mostly with RoR community. Finally, we choose … Ansible :)
Ansible uses SSH by default instead of requiring agents everywhere. Avoid extra open ports, improve security, eliminate “managing the management” and reclaim CPU cycles. It automates app deployment, configuration management, workflow orchestration and even cloud provisioning – all from one system. Shipping with nearly 200 modules in the core distribution, Ansible provides a vast library of building blocks for managing all kinds of IT tasks. With Ansible you could deploy with zero downtime.
Ansible works on “Playbooks” which are recipes – described in YAML – of the deployment process. You could find an adapt some examples of deploying Magento using Ansible. Examples which are pretty good and clear to understand: https://github.com/aslaen/AnsiblePlaybooks/tree/master/ansible-magento-lemp
Playbook could look like this:
--- - name: Download Magento Downloader get_url: url=http://www.magentocommerce.com/downloads/assets//magento-.tar.gz dest=/srv/magento-.tar.gz - name: Extract Archive command: chdir=/srv/ /bin/tar xvf magento-.tar.gz creates=/srv/magento - name: Add group "magento" group: name=magento - name: Add user "magento" user: name=magento group=magento home=/srv/magento/ - name: Change ownership of Magento installation file: path=/srv/magento/ owner=magento group=magento state=directory recurse=yes - name: Create Magento database mysql_db: name= state=present - name: Create Magento database user mysql_user: name= password= priv= state=present with_items: - php - php-fpm - php-enchant - php-IDNA_Convert - php-mbstring - php-mysql - php-PHPMailer - php-process - php-simplepie - php-xml - php-mcrypt - php-gd - name: Disable default pool command: mv /etc/php-fpm.d/www.conf /etc/php-fpm.d/www.disabled creates=/etc/php-fpm.d/www.disabled notify: restart php-fpm - name: Copy php-fpm configuration template: src=magento.conf dest=/etc/php-fpm.d/ notify: restart php-fpm }.*:ALL host='localhost' state=present
Having such playbook all You need to do is to enter one command in the shell to prepare the environment. The example above is extremely simple. In real word, You could prepare more servers – using, for example, Amazon Cloud Services.
That’s all for now :) We try to do things as simple as it’s possible.
What is Your preferred method of doing deployments and manage software lifecycle?