Deploying applications without headaches

When you look for information on methods to work more efficiently in software development is lots of very useful and well designed systems.Unfortunately these systems are usually oriented to large programming teams and never to small or very small teams, even one.

There are many small businesses, many more companies with large development teams, but unfortunately are the forgotten when specific systems for them.

For example kanban is a working system based on cards originally created by Toyota and is quite useful, but in teams of 2 or 3 people is not very efficient.

It is true that as small teams organized in teams is much easier, but it never hurts to have certain tools, certain organization to carry out its task more efficiently.

Many will relate to how some developments, including those for large applications, which manage large databases, raising the program files by FTP to the production server directly, making changes by hand on the same server, not having versions of what is deployed, did not work and return to the backup that was before, etc … This is a simple solution following a guidelines that are possibly easier to follow than the whole process of uploading files from Filezilla .

In my case, used to working in small environments I follow a pattern (I must say that sometimes jump me :)) quite simple in application development. Virtually all developments that have been made for others, and has much the customer to see that everything works properly.

Development process.

The first thing I do to start a development is the preparation, that is, have everything ready to program. What will I need to develop a web determines such. Normally need an editor or IDE, normally SublimeText2, and if it is very big project sometimes use NetBeans. I also need to install git for version control, a place to create a central repository for sharing, usually Github and some ancillary tools, such as Stylus to create the CSS if needed, processor Markdown to HTML in some cases, maybe some scrapping program because I take some data from a particular website or liquid to generate templates (these are only examples).

Once everything is prepared and transmitted to all the team created a folder for the development to which I put the name of the folder within my application code in Home , and created a git init to initialize the version control.

After the branches I think I need to develop. All team members employ two main branches,master and dev . Master is the main branch, ie, which will be responsible for production, which in principle is not touched until they are sure that it works. Dev is one where we will have developing the program, but here we do not schedule anything, we create branches of this industry in order to create the program, and once tested together with the development branch.

When you have tried everything then it all together on branch master , keeping open the branch dev and label that commit to the master branch as the version.

Another aspect to consider is the use of units of our program. If we are to use one or more libraries made ​​by us or made ​​by third parties to our project, we use composer, enabling us to meet all the needs of the units, for example if we use a framework like CodeIgniter orSymfony , or use any component as templates Mustache for example. Composer is primarily designed to work with PHP as it is communities like python, ruby or node have their own composer. Therefore composer becomes part of the project, but then do not send it to production.

All files are not deployed we put it in a file to disregard them and can then read our script when sending. We also create a file . gitignore files allowing take our repository.

Of course we also use a system of letters rather issues on github, to keep up with 3 things: What did each yesterday, what problems have arisen? and What will I do today? With this we cover data the information we need if the work is well distributed. Moreover, although only one is the developer, it is important to continue this pattern for yourself because you always have a clearer idea of the time in which the project is.

Tests.

Once we completed development testing in the testing phase, and unit test. Much less do test for everything, but for critical parts (I know it should be for all, but sometimes I feel that I do more test that effective programming). It is also very important to check the use of the database, of course without using the production database. It may be a copy (which is always convenient or if it is too large you can generate a random from a script data. Several scripts that keep semireales data in a database. In my case I have one made ​​for these circumstances . Forget about filling the database test1 , test2 and test3 , because there are many cases in which we need to check a larger amount of data, e.g for searching or paging.

Here the performance tests are also done. Check that the performance is adequate and record everything that is susceptible of improvement and then create a branch of fixes to improve these parts.

Once everything fits and specifications have been validated with the corresponding test. If everything is OK, you have to pass it to production.

Pre-production.

In pre-production can be tested in a closed test environment for the client, or if the evidence is for us this part would be integrated into the above.

For the pre-production and make sure everything goes well, we use the same method to deploy in production, but in a limited environment, usually or vps for this test or a virtual machine on our team. There is deployed and tested. If all goes well go down production. This does not usually do actually, only in cases where you have to show it to a client or the amount of changes made so large that has exponentially increased the possibility of bug.

Production.

Finally we reached the production phase and the deployment of the application server at the end, where we will keep smaller process (but this is another story that I will tell in the future, the short process of continuous maintenance and development).

For this task there are several tools that we can use.

It is very reliable and easy to use ftp to upload. Maybe a good option would be to do a git pull from the production server, but some git communication is not entirely safe and the other not set or doing chores we should do, such as starting the database .

For this we use capistrano, to configure a simple form which will despleagar, where and how.Once configured it takes care of everything. Ssh connects check how everything compiles if necessary, update the dependencies, etc … all up and presto! All set.

There are other applications. Capistrano is made ​​of ruby and its version Symfony2 capifony .Also Magallanes being done in php. We can also develop it ourselves based scripts.

Post-production.

In post there are four important parts to do:

  1. Here the best option, at least for me, is to have a cron that we generate a copy of the content and what versions every X time. These copies sent to Dropbox, S3, another server, or whatever, but obviously not in the same place.
  2. Another important aspect to consider is the online maintenance. This has to monitor it. It can be done with a small script to ping the server and deployed another check that everything is working properly or used tools (usually payment) with New Relic script.
  3. You have to have enough scripts to keep the application running and checking its functionality to go if a fault can be passed to fix as quickly as possible.
  4. If we have a continuous maintenance contract with a client or is our application, we must improve and update the product constantly. This allows us to open our git development branch, so that when we have a new request can get to it.

In summary.

We divided the work into four phases and keep two version control.

  1. Development: Version Control with Git.
    1. Major Release.
    2. Development version.
      1. Branches error correction.
      2. Branches of new features.
    3. Preproduction:
      1. Test unit for more complex parts (this is just to do some functions to verify that it does what it should).
      2. Data to the test database.
      3. Virtual environment not necessary in many cases : Creating a controlled live test and approval of the customer environment.
    4. Production:
      1. Configure capistrano to deploy or the like.
      2. Automated deployment.
    5. Postproduction This really is a second separate part of the main process .
      1. Control of state.
      2. Bugs Correction to the development branch.
      3. Improvements to the development branch.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top