November 4, 2012 at 14:20Continuous Delivery PHP Application
I want to share the experience of trying to implement continuous integration and "painless" deployment for php applications. I will try to consider some aspects on this issue:
Continuous Integration (Eng. Continuous Integration) - this is the practice of software development, which consists in the implementation of frequent automated assemblies of the project for the speedy identification and solution of integration problems.
When I first heard about CI, for me it was something incomprehensibly transcendental. I tried to figure out what it was. A little googling, I came across a phpUnderControl which is an add-on to CruiseControl and stories about how cool it is and that with it you can continuously pour on server production.
I picked it up on my LAN, connected everything that came into view to it, as a result I 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 did not find a deploy anywhere. The concepts of "build" and php in my head did not fit in any way, so over time CI abandoned it.
Some time passed, during which I managed to delve deeper into the front-end and the question of precompiling LESS in CSS with optimization of r.js on dev servers got an edge - I decided to deal with CI nevertheless. Since everything was rebuilt on the fly in the local environment on the fact of saving the file or by the usual launch of grunt, there were no problems.
The question was resolved quickly: he raised Jenkins on the server, made him a task that pulled the latest revision from the repository by the crown, and if it found something, launched grunt. In case of errors when starting grunt (someone messed up in the less file, or linting js code did not pass), notifications immediately arrived. Nginx was configured to proxy this task on the workspace and now you can watch everything collected on the dev server. Everyone is happy, the problem is resolved.
In summary, Continuous Integration is a practice for constantly monitoring the state of an application. If there is a minimal set of functional and integration tests, you can immediately notice if any part falls off and, by committing, track down the culprit.
Deploying is the process of deploying an application in various environments. Everything happens in a similar way:
All this can be automated by binding to our Jenkins server as a separate task. Yes, Jenkins not only works in snoop mode. By specifying all the servers and access to ssh, you can upload everything with the click of a button.
So far, everything goes in one branch of the repository and you can accidentally deploy something wrong. Now we will fix this situation.
We divide the development into 2 branches, dev and stable, where in dev we conduct the main development, and then we are ready to merge it into stable and hang the version tag. In reality, there are not 2, but many more, and you can devote a whole topic to it, but for now you can just get to know A successful Git branching model , where everything is pretty well described.
In order not to do everything manually, we will do additional tasking in Jenkins, which will merge stable with dev and hang a tag.
We have a stable branch, why not monitor it too? Let's do a similar task with the "Dev CI job", which will monitor this kitchen, plus add another host for nginx.
Now we have a certain pipeline (pipeling), with points I marked tasks that are called manually.
Stage CI job is called only if Make release is successful.
It looks better now, now we will connect testers.
We now have a more or less convenient release and deployment management system. 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 take their soul and they can show customers the product. Pour it on production or not, the latter decide.
Now we are moving towards testing automation using Selenium tools, because it’s no secret that integration and unit tests that developers write do not protect against bugs. Therefore, after the "Stage CI job" one more step will be added that will conduct system and functional testing.
Most likely we will come to a similar scheme, because for some developers it may be necessary to have their own sandbox to show ready-made features. In the QA team, you will also need several sandboxes so that they do not interfere with each other. And a separate sandbox for stress testing to look for bottlenecks in the application.
- What is Continuous Integration?
- What is deploying, how does it fit into CI
- A little bit about testing in the framework of this "conveyor"
Continuous integration - what is it?
Continuous Integration (Eng. Continuous Integration) - this is the practice of software development, which consists in the implementation of frequent automated assemblies of the project for the speedy identification and solution of integration problems.
When I first heard about CI, for me it was something incomprehensibly transcendental. I tried to figure out what it was. A little googling, I came across a phpUnderControl which is an add-on to CruiseControl and stories about how cool it is and that with it you can continuously pour on server production.
I picked it up on my LAN, connected everything that came into view to it, as a result I 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 did not find a deploy anywhere. The concepts of "build" and php in my head did not fit in any way, so over time CI abandoned it.
Some time passed, during which I managed to delve deeper into the front-end and the question of precompiling LESS in CSS with optimization of r.js on dev servers got an edge - I decided to deal with CI nevertheless. Since everything was rebuilt on the fly in the local environment on the fact of saving the file or by the usual launch of grunt, there were no problems.
The question was resolved quickly: he raised Jenkins on the server, made him a task that pulled the latest revision from the repository by the crown, and if it found something, launched grunt. In case of errors when starting grunt (someone messed up in the less file, or linting js code did not pass), notifications immediately arrived. Nginx was configured to proxy this task on the workspace and now you can watch everything collected on the dev server. Everyone is happy, the problem is resolved.
In summary, Continuous Integration is a practice for constantly monitoring the state of an application. If there is a minimal set of functional and integration tests, you can immediately notice if any part falls off and, by committing, track down the culprit.
Cool, but how to deploy it?
Deploying is the process of deploying an application in various environments. Everything happens in a similar way:
- through ssh we go to the server
- do pull from the repository
- in our case, we also run phing, which is followed by grunt
- profit
- repeat this on all production servers
All this can be automated by binding to our Jenkins server as a separate task. Yes, Jenkins not only works in snoop mode. By specifying all the servers and access to ssh, you can upload everything with the click of a button.
So far, everything goes in one branch of the repository and you can accidentally deploy something wrong. Now we will fix this situation.
Building and php - can you still connect?
We divide the development into 2 branches, dev and stable, where in dev we conduct the main development, and then we are ready to merge it into stable and hang the version tag. In reality, there are not 2, but many more, and you can devote a whole topic to it, but for now you can just get to know A successful Git branching model , where everything is pretty well described.
In order not to do everything manually, we will do additional tasking in Jenkins, which will merge stable with dev and hang a tag.
We have a stable branch, why not monitor it too? Let's do a similar task with the "Dev CI job", which will monitor this kitchen, plus add another host for nginx.
Now we have a certain pipeline (pipeling), with points I marked tasks that are called manually.
Stage CI job is called only if Make release is successful.
It looks better now, now we will connect testers.
Testing and release previews
We now have a more or less convenient release and deployment management system. 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 take their soul and they can show customers the product. Pour it on production or not, the latter decide.
Now we are moving towards testing automation using Selenium tools, because it’s no secret that integration and unit tests that developers write do not protect against bugs. Therefore, after the "Stage CI job" one more step will be added that will conduct system and functional testing.
Most likely we will come to a similar scheme, because for some developers it may be necessary to have their own sandbox to show ready-made features. In the QA team, you will also need several sandboxes so that they do not interfere with each other. And a separate sandbox for stress testing to look for bottlenecks in the application.