In big companies there is a proper structure from project development to project deployment and maintenance. On general level, It flows from Developer who develop any feature and DevOps who managed deployments and releases. It helps developer to focus on development and avoid unnecessary time wastage on deployments.
But in smaller companies, development and deployments both are handled by developer or sometimes deployments are handled by a super busy project manager and developer can focus on their code. So we as a manager should have knowledge to manage deployments efficiently. We will learn everything in this article.
What is CI/CD?
This is itself a big topic and can be explained in a separate article but for now let’s understand it in a very basic language. Continuous Integration(CI)/Continuous Delivery is a way to manage delivery of smaller features as they are ready in a live project so that we don’t have a whole lot of code to deploy. Suppose a project is launched and now we have 2 more features which we are developing side by side then as soon feature 1 completed it can be integrated in live and same with feature 2.
General deployment method
Most often, we work on a development branch and integration takes place by manual merging development branch to production branch in git repository and takes pull on live server. All developers work on the same development branch which is fine for a small project and team but can be a bad setup for big project
Problems with general deployment and manual integration?
Generally, when we take pull on production server then we have to face a lot of conflict and until we fix those conflict our website is down. This may create a problem for a live website and also loose some potential clients.
Better setup according to me
As I am assuming you are using git so let’s improve our branch management work flow. I suggest to create 3 main branches:
1. Master – Production Branch
2. Staging – Approved Features and ready to release
3. Development – All developers will raise pull request here and testing will be done on this code
All above branches should be protected branches on a main github account and developer and designers has to fork only development branch and work on their own version of code. Off course, there will be 3 servers (Live, Staging, Development) to check website. Tester will test merged code on development and once approved give green signal to manager to merge changes in Staging to keep feature ready for faster release.
Feature-wise or bug-wise temporary branches and merging in development branch
Developers will create new temporary feature branches from development and nomenclature of branches will be either feature name or bug id. Once the bug is fixed or feature is complete developers will create pull request for that feature branch. Once feature is approved by manager then developer have option to delete this temporary branch and take upstream pull on development branch to have approved changes.
Manager handling Pull Requests
Manager will review all pull requests on development branch and approve changes if looks good. Then tester is notified to test the feature on testing server and if approved feature merged in Staging branch for release with some tags. Whenever, manager want to release any specific release, manager can merge that feature on master branch. There is a minimal chance of any conflict on development branch because of review step by manager through pull request. If there is any code conflict then manager can reject PR(Pull Request) or have discussion with developer to resolve that. It will keep clean history on development branch.
More cleaner commit history on staging branch and almost 0% chances of conflict on live server
Development branch will have a clean commit history and we are merging features from development to staging so minimal chances conflict here but all possible conflict will be filtered on this stage so merge will be clean on master branch and there are 0% chances of any conflict on live server.
Next Step is to integrate CI/CD:
Now we have a basic setup which can be used to integrate CI/CD. At this moment we have reduced chances of conflict on live server but pulls on servers are still manually handled. This process should be automated to avoid unnecessary delay. Now we can implement any CI/CD tool to automate deployments and ensure 0% downtime during deployments. There are many CI/CD tools out of which Jenkins and AWS CodePipeline are popular. Click Here to read next article, I will share more details about AWS CodePipeline and also share detailed steps to setup AWS codePipeline.
