We are not carpenters, not carpenters ... And we are programmers-workers, yes. And install applications on servers of several environments
Good day friends.
Honestly, I’m already tired of supporting versions of applications on servers and making changes to the hand-to-hand database. I use my installation scripts - the same programs that I also need to monitor myself and edit in different circumstances, such as adding a new server or preparing a new virtual machine for testers. I wanted to see what civilized solutions are for such tasks. I want to share my first experience in software deployment automation environment - Serena Deployment Automation (SDA) - the product is free, provided it is used on no more than 5 servers.
Using SDA, you can automate and consolidate such operations as:
')
1. Obtaining source code from various sources - file system, version control environments (Git, Subversion, etc.)
2. Build code through Jenkins integration, Apache Maven, etc.
3. Simulation of delivery scenarios and installation of changes for the entire application or its individual components. This may include simple tasks, such as transferring files, as well as more complex ones, such as running data update scripts in the database, installing web applications on IIS, Aphache and other web servers, running various scripts, taking snapshots of virtual machines, running tests after installation, etc.
4. Manual and delayed deployment deployment, tracking installation progress, viewing logs.
5. Sequential or parallel installation on several environments (for example, on test and combat or on several combat).
And so on. The possibilities are quite extensive. It is important that absolutely all configuration occurs through the general web interface of the system.
I’ll start by creating a process for deploying a small .aspx report. The report provides information from the database in MS SQL and is hosted on the IIS web server. We also have a SQL Update script for updating data, which needs to be executed after installing the latest version.
To begin with, let's set up getting code from the Git repository. To do this, create a new component, give it a name, specify the branch and the path to the Git client:
SQL scripts are stored in a separate repository. Similarly, create a component for them.
Next, go to the description of the installation process of each component. The process of installing an aspx report is presented below:
The first step loads all artifacts (files) into the directory I need on the server, the second step restarts the web server via the command line.
The list of available operations for interacting with various systems is determined by the plugins used. The composition of the SDA includes about 80 pieces. If interested, the full list can be found here .
A separate process describes the launch of SQL scripts. The scheme is similar - the scripts are uploaded to the server and then run (via sqlcmd):
How does SDA perform all these actions on a remote server? Through a separate agent program available for various platforms. Those. SDA agent must be installed on the server. Sometimes it is impossible. In this case, the so-called “agentless” configuration is used when the deployment occurs without the involvement of agents. A typical scenario - we connect to the server via SSH, from the command line we run commands to update the source files from the same Git, copy the files into the necessary folders, restart the processes, if necessary. This is a direct course of events. And everywhere you need to check that there is space on the disk, that all the files are received, that everything has been copied to the right place, etc. etc. And provide for actions to roll back and clean up the server after their actions.
The unifying element will be the configuration object, which in the system is called "Application". Let's create one and start its configuration by adding our components:
Next, set up the environment (the word “environment” is more appropriate here, because there may be many servers) on which we will perform the deployment:
And the last. Create a process that integrates the installation procedures for both of our components (application process):
That's all, now let's start the process. You can monitor the deployment status in real-time mode:
Or see the results after completion:
Execution logs are stored inside each step. If something went wrong, it will be immediately visible. For example, here are the execution logs of the SQL-update script:
So far my example is too simple to recommend something or evaluate the suitability of the approach.
What else should you try:
Look at the beautiful pictures, read the manufacturer's description and download all this stuff here .
Actually, that's all. I hope that the topic of automating deployment processes is interesting to someone. Please ask questions in the comments. Very interesting what you think about it.
Honestly, I’m already tired of supporting versions of applications on servers and making changes to the hand-to-hand database. I use my installation scripts - the same programs that I also need to monitor myself and edit in different circumstances, such as adding a new server or preparing a new virtual machine for testers. I wanted to see what civilized solutions are for such tasks. I want to share my first experience in software deployment automation environment - Serena Deployment Automation (SDA) - the product is free, provided it is used on no more than 5 servers.
Using SDA, you can automate and consolidate such operations as:
')
1. Obtaining source code from various sources - file system, version control environments (Git, Subversion, etc.)
2. Build code through Jenkins integration, Apache Maven, etc.
3. Simulation of delivery scenarios and installation of changes for the entire application or its individual components. This may include simple tasks, such as transferring files, as well as more complex ones, such as running data update scripts in the database, installing web applications on IIS, Aphache and other web servers, running various scripts, taking snapshots of virtual machines, running tests after installation, etc.
4. Manual and delayed deployment deployment, tracking installation progress, viewing logs.
5. Sequential or parallel installation on several environments (for example, on test and combat or on several combat).
And so on. The possibilities are quite extensive. It is important that absolutely all configuration occurs through the general web interface of the system.
I’ll start by creating a process for deploying a small .aspx report. The report provides information from the database in MS SQL and is hosted on the IIS web server. We also have a SQL Update script for updating data, which needs to be executed after installing the latest version.
To begin with, let's set up getting code from the Git repository. To do this, create a new component, give it a name, specify the branch and the path to the Git client:
SQL scripts are stored in a separate repository. Similarly, create a component for them.
Next, go to the description of the installation process of each component. The process of installing an aspx report is presented below:
The first step loads all artifacts (files) into the directory I need on the server, the second step restarts the web server via the command line.
The list of available operations for interacting with various systems is determined by the plugins used. The composition of the SDA includes about 80 pieces. If interested, the full list can be found here .
A separate process describes the launch of SQL scripts. The scheme is similar - the scripts are uploaded to the server and then run (via sqlcmd):
How does SDA perform all these actions on a remote server? Through a separate agent program available for various platforms. Those. SDA agent must be installed on the server. Sometimes it is impossible. In this case, the so-called “agentless” configuration is used when the deployment occurs without the involvement of agents. A typical scenario - we connect to the server via SSH, from the command line we run commands to update the source files from the same Git, copy the files into the necessary folders, restart the processes, if necessary. This is a direct course of events. And everywhere you need to check that there is space on the disk, that all the files are received, that everything has been copied to the right place, etc. etc. And provide for actions to roll back and clean up the server after their actions.
The unifying element will be the configuration object, which in the system is called "Application". Let's create one and start its configuration by adding our components:
Next, set up the environment (the word “environment” is more appropriate here, because there may be many servers) on which we will perform the deployment:
And the last. Create a process that integrates the installation procedures for both of our components (application process):
That's all, now let's start the process. You can monitor the deployment status in real-time mode:
Or see the results after completion:
Execution logs are stored inside each step. If something went wrong, it will be immediately visible. For example, here are the execution logs of the SQL-update script:
Conclusion
So far my example is too simple to recommend something or evaluate the suitability of the approach.
What else should you try:
- How easy and convenient it will be to configure the version without an agent, since in most cases, hosting will not allow the SDA agent to be installed, including all necessary checks after each action
- We need to see how to add error handling, rollbacks and restore the previous version to our script.
- Try running tests after deployment
Look at the beautiful pictures, read the manufacturer's description and download all this stuff here .
Actually, that's all. I hope that the topic of automating deployment processes is interesting to someone. Please ask questions in the comments. Very interesting what you think about it.
Source: https://habr.com/ru/post/276505/
All Articles