The Intraway Installer is a solution designed for managing the deployment and configuration of a variable of software components. Each component could be related either to an Intraway product or to a piece of base software. This solution required adopting some market-proven software engineering practices. Some of them were new, while others were not so new. At the end of the day, a team may be able to obtain a single installer package for an entire product that will automatically do in minutes, what in the past took weeks.
Want to know what else we’ve been working on? Keep reading! Quality in software development and delivery chain
Since 2015, and after a customer satisfaction survey, our Delivery Department established three main objectives:
- Automate installations and upgrade processes
- Update component versions and supported OSs
- Automate and homogenize testing environments
On the other hand, the company’s board set other two main transversal requirements:
- Automate everything
- Amazing delivery: Delivery X2
The Technology Team worked for some time on implementing our first complete CI cycle. Based on this work, we proposed an extensive installer architecture. Both the CI cycle and the Installer solution will provide two important benefits: better releasing and deployment.
The Architecture of the Intraway Installer
This solution is composed of three main layers:
Is a command line application which provides a user interface that allows the operator to change installation parameters.
Is responsible for configuring the entire environment. It includes managing the application’s deployment and configurations, creating users, setting cron jobs and more.
A YUM Repository
Is where all our application’s releases will be stored. We want the OS’s package manager taking charge of what is installed, in what version, and what dependencies are required.
Installer solution diagram
Installer Solution Diagram: The Three Layers and Their Owners
As you can see in the image above, the Technology team is responsible for maintaining both the Installer and the YUM Repository, along with automating the RPM generation.
The Puppet recipes for every application are the Delivery team’s responsibility.
Every Intraway application project can implement this solution simply by meeting four main requirements:
- RPM Generation
- Puppet Recipes
- Database Versioning
- Configuration Standards
We’ve decided to make use of the OS’s package manager to handle our applications’ deployment and its dependencies. Since we are only supporting RHEL-based OSs, we base our solution on RPM packages.
Our current CI machinery does the job for you. You only need to meet SCM requirements and Jenkins will make and publish RPMs for you.
Puppet provides a declarative scripting language to define resources and their state. Resources are things such as packages, files, services, and crones, in a state such as the present, absent or running.
Puppet is good at handling server (or environment) resources. We want the Installer Solution to make use of such capabilities to install and configure all that is necessary for our products to run properly.
To accomplish this, we proposed creating a Puppet Module and a Recipe for each application. The module will handle the application specifics and the recipe will handle all the modules required for the application to work.
We’re using Flyway, a database migration tool, which requires versioning the databases. Every change in the database schemas will be checked and approved by DBA team. After that, the script will be added to the database schema repository.
One or more script will make a baseline. Then another group of scripts will migrate that baseline into a new version, and so on.
It is mandatory for every application to implement the configuration standard defined by each programming language. This way we are able to lower configuration complexity and introduce automation tools such as Hiera.
Know more about the company! Intraway’s Scrum Implementation Story