Continous Integration in Ackee in Nette developer´s perspective

In Ackee Continuous Integration is used for web application development. I'll explain you why this helps us, Nette programmers and how it simplifies our work.

How does it work ?

The whole system is based on Jenkins CI CI and a few scripts. At a time when the developer will contribute to the repository, GIT post-commit-hookem sends a notification to Jenkins. If there is a deploy configuration in Jenkins for particular branch in the repository, then the whole process is started.

Configuring Nette Application

First of all, files from a branch in the repository are copied. Into Nette application configuration files is then recorded everything, that is needed to run the application on the target server. Credintials for the access to the database, keys to various API and everything else the application needs is added. Each branch in the repository can have its own configuration, so it is possible to make deploy for testing purposes for us and even for the consumer. The same procedure is implemented also in production deployement.

Most often it is set to deploy the following purposes:

1. The development branch for developers testing,
2. internal test environment,
3. test environment for the customer ,
4. deployment to a production server.

When the configuration is completed, the original data (files and databases) are backed up and new version is uploaded on the target server.

Database migration

Building a database is done from the repository, where everything is stored in SQL scripts. The various versions of the database are numbered and when you create or update a database gradual deployment of all versions is made. Depending on the configuration there will be:

• Erased and the gradual implementation of SQL scripts. This is typical for testing servers.
• The gradual implementation of SQL scripts with a higher version than the current version of the database version. Valid for production server or servers for such a test, which for some reason kept the test data.

Benefits for developers

In terms of the developer, the solution is preferred in particular:

1. Full shielding developers from server issues,
2. robustness against errors,
3. automatication of the process (no need to dash admins),
4. everything a developer needs to affect is directly in the repository applications (SQL scripts, configuration files , ...),
5. developer works with the tool that he is familiar with (GIT) and does not need to learn to use another tool.