Developing for tomorrow, one dream at a time
So I’m going to write a series of articles on how my predecessor and I have made my job of deploying new code, and even new systems for our clients a task that takes a fraction of the time compared to the days it previously took us to deploy updates to our clients systems.
To Begin, I’ll give you some background. I work for a small company in Victoria, Australia. We provide a software solution to 30+ clients. This software solution is a web based system running in it’s own virtual space for our clients. The system runs on a linux system, with php building the webpages for the front-end and a java stack running between the php and a postgres database. Our code has been stored in cvs, and our company had custom code running on the majority of our clients instances of our software.
This key point (clients had custom code in the system) always made it difficult to deploy updates. I was given this wonderful task, and it always involved 8+ hours of merging code in the master branch into their system to deploy an update. I would generally do this part locally, copying their current code base locally, so the deployment of the update to a client caused minimal disruption to their day-to-day business. To make things even harder, the custom code was only on the clients systems (and the backups of those systems), not found in cvs.
About 2+ years ago we hired, a smart gentleman who introduced me to the way things should be done. The 2 concepts were a cicd pipeline (Continuous Integration/Continuous Deployment), and “IT automation and Configuration Management” . As part of this series, I will be taking you on my journey, as I was introduced to the underlying systems chosen for implementation, and the challenges I’ve had to overcome. I also have permission to release code I had to write for our solution.
The smart hire managed to get all of the pieces on the table as it were, before he handed it to me for implementation. So to begin, I’ll explain the software stack as a whole. So on our hardware nodes was a running OpenVZ, an open source version of Virtuozzo. This allows us to run containers running a full linux system. As mentioned above we are running linux containers for our clients with apache, php, and java, and a seperate linux system for the databases for our client’s systems. We chose gitblit for our git repo hosting system in-house, along with Jenkins for our CICD system, and SaltStack for our Configuration Management Solution.
In the next article, I will be discussing the implementation of our CICD pipeline, which allows us to automatically compile our code, and build and rpm ready for deployment to a client’s system in minutes.