Continuous Delivery PHP Applications
I want to share the experience of attempts to introduce continuous integration and "painless" deploing for php applications. I will try to consider some aspects on this issue:
Continuous Integration (Continuous Integration) is a software development practice that involves performing frequent automated project builds to identify and solve integration problems as quickly as possible.
When I first heard about CI, for me it was something incomprehensible, transcendental. I tried to figure out what it is. A little googling, I stumbled upon a phpUnderControl that goes with an add-on to CruiseControl and tells stories about how cool it is and that you can use it to continuously pour on the production server.
I picked it up on LAN, connected everything that came into view, and finally saw a bunch of different graphs and the possibility of viewing the status of tests. Cool, but what's the point if we don't write tests? How to make builds, and deploy nowhere not found. The concepts of “build” and php in my head didn’t bind at all, so over time CI abandoned it.
')
Some time passed, during which I managed to go deeper into the frontend and the issue of precompiling LESS in CSS with optimization of r.js on dev servers was an edge - I decided to still deal with CI. Since everything was rebuilt on the fly in the local environment after the file was saved or by the usual launch of grunt, there were no problems.
The question was resolved quickly: I picked up Jenkins on the server, made him a task that, according to the crown, pulled the last revision from the repository and if it found something, it launched grunt. In case of errors when launching grunt (in the less file, someone messed up, or the linting js code did not go through) notifications came immediately. Nginx was configured to proxy on the workspace of this task and now you can watch everything collected on the dev server. Everyone is happy, the problem is solved.
In summary, Continuous Integration is a practice for continuously monitoring the state of an application. If there is a minimum set of functional and integration tests, you can immediately notice if any part falls off and, by commit, track down the culprit.
Deploing is the process of deploying an application in various environments. Everything happens in a similar way:
This can all be automated by linking to our Jenkins server as a separate task. Yes, yes, Jenkins not only works in code tracking mode. Having specified all servers and accesses to ssh, it is possible to fill in everything by pressing of one button.
As long as everything goes in the same repository branch and you can accidentally fail to do that. Now we fix this situation.
We divide the development into 2 branches, dev and stable, where in dev we are conducting the main development, and what is already ready is merged into stable and hanged the version tag. In reality, there are not 2 of them, but a lot more and you can devote a whole topic to this, but for now you can just get acquainted with A successful Git branching model , where everything is described quite well.
In order not to do everything manually, we will do an additional task in Jenkins, which will merge stable with dev and hang the tag.
We have a stable branch, why not monitor it too? We will do a similar task with the “Dev CI job”, which will follow this kitchen plus add another host for nginx.
Now we have a pipeline (pipeling), with dots I marked the tasks that are called manually.
The “Stage CI job” is called only if the “Make release” was successful.
It looks better, now we will connect testers.
We now have a more or less convenient system for managing releases and deployment. Developers do not follow the process beyond the “Make release” step. We released a stable version and it went to the stage server, where testers can give a soul and can show the product to customers. Pour it on the production or not, decide the latter.
Now we are moving towards testing automation with Selenium tools, because it’s not a secret to anyone that the integration and unit tests that the developers write do not protect against bugs. Therefore, after the “Stage CI job,” one more step will be added, which will carry out systemic and functional testing.
Most likely we will come to a similar scheme, because some developers may need their own sandbox to show ready features. In QA, the team will also need several sandboxes so as not to interfere with each other. And a separate sandbox for load testing to look for bottlenecks in the application.
- What is Continuous Integration?
- What is deploing, how does it fit into CI
- A little about testing in the framework of this "conveyor"
Continuous integration - what is it?
Continuous Integration (Continuous Integration) is a software development practice that involves performing frequent automated project builds to identify and solve integration problems as quickly as possible.
When I first heard about CI, for me it was something incomprehensible, transcendental. I tried to figure out what it is. A little googling, I stumbled upon a phpUnderControl that goes with an add-on to CruiseControl and tells stories about how cool it is and that you can use it to continuously pour on the production server.
I picked it up on LAN, connected everything that came into view, and finally saw a bunch of different graphs and the possibility of viewing the status of tests. Cool, but what's the point if we don't write tests? How to make builds, and deploy nowhere not found. The concepts of “build” and php in my head didn’t bind at all, so over time CI abandoned it.
')
Some time passed, during which I managed to go deeper into the frontend and the issue of precompiling LESS in CSS with optimization of r.js on dev servers was an edge - I decided to still deal with CI. Since everything was rebuilt on the fly in the local environment after the file was saved or by the usual launch of grunt, there were no problems.
The question was resolved quickly: I picked up Jenkins on the server, made him a task that, according to the crown, pulled the last revision from the repository and if it found something, it launched grunt. In case of errors when launching grunt (in the less file, someone messed up, or the linting js code did not go through) notifications came immediately. Nginx was configured to proxy on the workspace of this task and now you can watch everything collected on the dev server. Everyone is happy, the problem is solved.
In summary, Continuous Integration is a practice for continuously monitoring the state of an application. If there is a minimum set of functional and integration tests, you can immediately notice if any part falls off and, by commit, track down the culprit.
Cool, and how to deploy it?
Deploing is the process of deploying an application in various environments. Everything happens in a similar way:
- via ssh go to the server
- do pull from repository
- in our case, we are also running phing, which grunt pulls
- profit
- repeat it on all production servers
This can all be automated by linking to our Jenkins server as a separate task. Yes, yes, Jenkins not only works in code tracking mode. Having specified all servers and accesses to ssh, it is possible to fill in everything by pressing of one button.
As long as everything goes in the same repository branch and you can accidentally fail to do that. Now we fix this situation.
Building and php - can you still link?
We divide the development into 2 branches, dev and stable, where in dev we are conducting the main development, and what is already ready is merged into stable and hanged the version tag. In reality, there are not 2 of them, but a lot more and you can devote a whole topic to this, but for now you can just get acquainted with A successful Git branching model , where everything is described quite well.
In order not to do everything manually, we will do an additional task in Jenkins, which will merge stable with dev and hang the tag.
We have a stable branch, why not monitor it too? We will do a similar task with the “Dev CI job”, which will follow this kitchen plus add another host for nginx.
Now we have a pipeline (pipeling), with dots I marked the tasks that are called manually.
The “Stage CI job” is called only if the “Make release” was successful.
It looks better, now we will connect testers.
Testing and preview of the release
We now have a more or less convenient system for managing releases and deployment. Developers do not follow the process beyond the “Make release” step. We released a stable version and it went to the stage server, where testers can give a soul and can show the product to customers. Pour it on the production or not, decide the latter.
Now we are moving towards testing automation with Selenium tools, because it’s not a secret to anyone that the integration and unit tests that the developers write do not protect against bugs. Therefore, after the “Stage CI job,” one more step will be added, which will carry out systemic and functional testing.
Most likely we will come to a similar scheme, because some developers may need their own sandbox to show ready features. In QA, the team will also need several sandboxes so as not to interfere with each other. And a separate sandbox for load testing to look for bottlenecks in the application.
Source: https://habr.com/ru/post/157335/
All Articles