A
A
Artur Bordenyuk2012-11-19 01:35:01
PHP
Artur Bordenyuk, 2012-11-19 01:35:01

How to properly deploy an application?

Hey!
Yesterday I realized that I was running my _business_ in some absolutely barbaric way. The use of git and bitbucket no longer surprises anyone.
Due to the long work of the conveyor, which releases bicycles according to my markings, it became necessary to facilitate some stages of work.
Right now there is my PC on which the _next_ site is being developed and two computers that can be called servers. To hell with it, two incredibly full-fledged servers - development and production servers. (and what scope?)
I honestly used Google, in a country in which there is no registry of illegal sites, and realized that my little problem was solved by:

  • Service POST on bitbucket side;
  • Some script for git pull on the development side of the server.

But my competence leaves much to be desired - I decided to master testing. I confess, even though I knew before the village, I did not take testing of any kind for granted. It's time to get much better!
I’ll somehow figure out the tests themselves, but where would it be _correct_ to run them? I have? Already on the server development side?
And suppose that the bike of my production came out in the form of a ready-made site on a dev server. The old-fashioned way, via ftp for production?
Is it possible for git to pull only updates to files that currently exist from a remote repository?
Those. there is a desire to make such operations as a result of which you can merge from the dev server to all the files of the site, but only part of them.
Please note that my questions may be asked completely incorrectly or not very correctly. Do not be angry. :-(

Answer the question

In order to leave comments, you need to log in

3 answer(s)
S
shebanoff, 2012-11-19
@HighQuality

I saw two parts in your question.

How to properly organize deployment (uploading working code to the server)?


In the simplest case, a bunch of ssh + git pull on the server will suit you. In this case, patches of commits that are in the repository but have not yet appeared on the server will be delivered to the server, i.e. "only updates to files that currently exist." This method has been discussed at some length in the answers to another question .
If you want to automate the process, which is commendable, then I see three tools available for this: Capistrano , Mina (my personal favorite) and Vlad the Deployer . All three projects are essentially the same. The principle of their work is as follows:
  1. Connect to the target server.
  2. Upload the code update from the repository.
  3. Follow the instructions prescribed by you (restarting daemons, resetting indexes, updating the database structure, etc.).
  4. ...
  5. PROFIT!

The tools are simple, switching to them is a matter of one weekend, and can only be difficult due to novelty.

How to organize the testing process?


If you have not yet decided on a testing methodology (Test Driven Development, Behavior Driven Development, Laziness-Driven Development), then you should start doing just that.
Most likely, the tests will be running on your local machine while you write the code. Using RSpec I keep the Guard open. Guard tracks code changes and runs a set of unit tests that cover the changed code. The whole process takes no more than a minute or two, and is not particularly annoying. As soon as I see a failed test, I change the code until it turns green. While there are few tests (this is not the best sign, by the way), you are working alone, a local launch before deployment may be enough - for example, to check the release for the availability of critical functionality: registration, purchases, creating posts, etc.
At some point, we may talk about Continious Integration. This is an opportunity to have a stable build at any time, as well as make a decision about the suitability of each individual commit. Associated with deploying the code to the integration server and running tests on it. Most likely, this does not interest you if you do not work in a team. But, to complete the picture, you can watch the Travis CI builds of famous Open Source projects: Symfony 2 and Ruby on Rails .

Thus


You didn't specify what specific development tools you use. If everything is much simpler with deployment, then when choosing tools for testing, I recommend that you focus on those that are native to your main framework and language (PHP, if I understand correctly) and are familiar to their users. This will allow you to quickly apply established practices to your project and understand everything in practice.
Tidy up your code repository, use mina to deploy and run tests on your local workstation. As soon as you feel that this is not enough, you will probably already know where to go next.

V
Vyacheslav Slinko, 2012-11-21
@KeepYourMind

My php stack:
- for tests: locally Behat ;
- for capifony deployment ; - for composer
modularity .

M
Michael, 2015-05-14
@Singaporian

You can't give good advice without knowing the language in which the application is being written. The choice of tools depends on the language. I can't recommend uDeploy for PHP, but it will do just fine for Java. You can't recommend Grunt for C++, but you can't go anywhere without it in JS. Etc.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question