Deployment component (building and publishing update packages, monitoring)

The Deployment component is designed to facilitate publication of your projects, monitoring of source code and production server databases as well as building of update packages.


Step 1 - Load the platform on the developer’s local machine, install the project, create a repository (if desired) in your source version control system (it can be SVN, GIt, Mercurial, etc.) and commit the files. Start your project development in a team or on your own.

Step 2 - The first publication of the project - simply copying the code and the project database to the production-server. After the system has been successfully copied, activate the API in the admin panel in production mode (just publish the API page) and create the API key in the API Keys section.

Step 3 - Now, on the developer’s localent machine you can connect to the API of the production system. You will need to create a server account. Go to Deploy section, add the server and enter the required data. The default url to the production system API-controller will be

That’s it. Now, you can track the source code for any third party changes, collect update packages for a specific production-server if needed, check the status of the production database. There is no need to configure the svn client on the production-system as updates will be installed upon your request only, besides, only the files specified by you will be updated, so you won’t have to trouble yourself with export from the data version control system anymore.


The Deploy module generates a background task, which sends a map request to the selected server. The server receives the request, runs the file system of the project, making up its map from the list of existing files and their checksums. The generated map is sent to the requesting client.

Upon getting the map of the remote server, the local system can compare it with the map of its file system being considered as standard. The interface displays all the differences between the maps shown in two panels for convenience, the first panel listing the files to be updated, the second one - the files to be possibly removed.

Once the comparison is finished, the developer can select the files for the current update by ticking the relevant checkboxes and clicking Create Package, collect a zip-archive of the files for update and upload the files to the server. The archive is built preserving the file structure of the project, thus, files are updated by simply being replaced with new ones.


The list of production-servers (panel 1):

Synchronization panel (Panel 2), which becomes available upon adding a server.

Window for adding a new production-server:

‘Server ID’ and ‘Server name’ fields are used to identify a server in the project. Enter the identifiers convenient for you.

‘Server API url’ field - the default url for the API-controller of the production system looks like this:

‘Server API Key’ field - the key for accessing the server. The keys are created in the API Keys section for the server, which provides the API access.

Before starting synchronization, you need to update standard file system mask (button 4). In panel 2, there is a button requesting information from a remote server. Clicking it will run a background task requesting the file system mask or the database statistics from the remote server (as per the tab opened).

Once the background task is performed, the Files tab of the Server panel will show two tree-like lists of files. New or updated files of the local server should be sent to the production, while the production-server files, not matching any of the files on the local machine are likely to be removed.

‘Create package’ button creates a background task for building an update patch. Once the task has been finished, the Deploy directory, which is parent to document root on the local machine, will show a file archive to be uploaded to the remote server, after which the system may be updated. At this stage, the step involving sending the archive to the remote system presupposes manual upload. The process will be automated for future releases. Besides the files to be updated, the archive will include a text document with the names of the files to be deleted.

The ‘Database’ tab currently only displays information on the ORM remote server status. We plan on expanding the functionality later on:


Prior to publishing, make sure that all code packages are relevant, and recompile them if necessary (Code Compiler interface).


Here is an example of setting up a project infrastructure:

  • creating a local project, developing the product;
  • publishing the project to the production-server;
  • starting command development, connecting SVN;
  • expanding the project / publishing the application to another production-server;
  • increasing the application performance on the second server, allocating an additional web server, separating system cache (common for all servers) and data cache (unique for each server), clustering MySQL.