{"id":4327,"date":"2014-12-02T09:00:34","date_gmt":"2014-12-02T11:00:34","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=4327"},"modified":"2015-06-01T12:25:25","modified_gmt":"2015-06-01T15:25:25","slug":"the-pros-and-cons-of-4-deployment-process-techniques","status":"publish","type":"post","link":"http:\/\/blog.plataformatec.com.br\/2014\/12\/the-pros-and-cons-of-4-deployment-process-techniques\/","title":{"rendered":"The pros and cons of 4 deployment process techniques"},"content":{"rendered":"

The way of deliver your product code to your customer is commonly called “deployment”. It is an important matter because it will impact in how fast your product will respond to changes and the quality of each change.<\/p>\n

Depending on which deployment decision you take, it will impact your team and how you use your version control system.<\/p>\n

As a consultancy, we have worked in lots of projects, and together with our customers we have devised many ways to deliver their product to their customers. We have seen some patterns, advantages and challenges on each way, and today I would like to discuss some of them:<\/p>\n

    \n
  1. The open-source way<\/a><\/li>\n
  2. The pipeline way<\/a><\/li>\n
  3. The support branch way<\/a><\/li>\n
  4. The feature toggle way<\/a><\/li>\n<\/ol>\n

    The open-source way<\/h2>\n

    In the open-source world most of the times we should maintain many versions of a same product. For example, Ruby on Rails has many versions released, like 2, 3.2, 4.0, 4.1. Bugs happens, new features are created, so news releases must be delivered, but in a set of supported released versions. Still on RoR example, the supported releases are 4.1, 4.0 and 3.2 (http:\/\/guides.rubyonrails.org\/maintenance_policy.html<\/a>). But how this releasing works?<\/p>\n

    The most recent version of the product is maintained on the master branch, the previous major releases have their own branches. On RoR we have the master for the new 4.2 version release, and we still have 4-1-stable, 4-0-stable, 3-2-stable branches. By following this organization we can easily apply changes on the desired versions.<\/p>\n

    For each release a tag must be created. For example, there’s a tag for RoR 4.0.0, one for 4.1.0 and so on. With tags it is possible to navigate between the released versions and if the worst happens, like losing the “version-stable” branch, it’s easy to create another one from the last released version.<\/p>\n

    Usually, a web product has just one version to be maintained, so usually we don’t need the “version-stable” branches. We can keep the new product releases on the master branch and generate a tag when we want to package and release a new product version.<\/p>\n

    When we need a “hotfix” or an urgent feature and the master is not ready yet for production, we can easily create a branch from the latest tagged version, apply the desired changes, create a new tag and release a new version. By the way, using this way you can release any branch you want. All that manipulation of applying commits, merging and creating branches and tags, can be simplified with a powerful version control system like “Git”.<\/p>\n

    Strong points<\/h3>\n