When the developer has built the desired application, the SDLC’s next step is to deploy it for testing purposes. The process of delivering the application code to specific customers is known as deployment. It is an essential aspect of application development because it impacts the quick response of applications in time and new changes. The quality to adopt change and deliver a fast response time of the product depends upon the deployment method. Another essential thing in deployment is that the user sometimes doesn’t have to have access to any features due to the various environments in which the application works.
Automated deployment ensures the transition of software code between testing environments and production environments. The developers perform this movement by implementing automated processes. These automated processes provide the ability to repeat the process and deploy the code reliably throughout the whole software delivery cycle. The benefit of automated deployment is that it makes the developers release new features and applications quickly and more often. Moreover, it also prevents any delay or error caused by human intervention during application deployment.
With deployment automation, it has become easier to deploy applications across diverse existing deployment and production environments. The key features of deployment automation are application development, modeling environment, and workflow orchestration. A research report from Enterprise Management Associates claims that increasing 10% or more continuous delivery frequency benefits the companies to experience 10% or more revenue. Therefore, companies are always trying to maximize efficiency and minimize feedback loop by incorporating automated deployment in their products. Following is the list of some of the best automation tools used to achieve this evolutionary deployment automation:
GitHub’s auto-deployment allows the developers to deploy the updated code on their live servers as soon as they make changes on the remote repositories. Although there are numerous ways to utilize adobe mentioned tools for automated application deployment, a simpler and more convenient way of such deployment is using Git Hooks.
In GitHub, the scripts that are triggered automatically whenever a particular event occurs are called git hooks. The Git Hooks are code scripts, mainly in shell or PERL, and can exist on the server-side repositories or the local side. However, the users need to install the hooks by removing the .sample extension from the Git repository.
When the users work on the Master branch or local repository, they mostly have to push their codes to some remote server such as GitHub and export or pull it to the production server, which is too time-consuming. Sometimes, they use available services on the internet to act on the webhooks that have triggered that service.
Although these services help the user deploy the code automatically, they provide less flexibility and customizing options with lots of restrictions, which are not favorable for the users in some scenarios.
However, in this article, the user takes control in his hands to add his repository that he created on the production server and publishes it directly on the server. In this case, where there is no second party service, the user has complete control and flexibility due to the use of .sh scripts for deployment with no security concerns involved in using second-party services.
These are some pre-conditions on the user-part before starting deploying his code:
Below are the steps to create an automatic deployment from the user’s local repository (master or branch) to the server:
Create a folder on the production server to which the user has to deploy their code. The users can do this by using Secure Shell (SSH) in the production server.
$ ssh email@example.com
$ mkdir ~/deploy-folder
The next step is to create the bare repository and it on the production server. The bare repository can have any name of the user’s choice. This repository is the one that does not contain the working-copy files. Mainly, it is the mere copy of the .git repository folder’s content.
$ git init --bare ~/project.git
Note: the users can also write the project without the “.git” extension. This extension typically creates this repository in an already existing empty folder.
After creating the repository, the next step is to add a post-receive hook script to it. These hook scripts execute automatically each time a new event takes place in the repository. Furthermore, they help customize git’s internal behavior and trigger customized actions in the development life cycle. After executing push from the local machine, this hook script executes and moves the files into specified places. This hook is usually in the repository name/hook path, and its name is “post-receive.” Vim is used to create and update it. This script ensures the pushing of a correct branch.
chmod +x post-receive
Adding a remote repository is an essential step after the addition of the post-receive hook. In this step, add the former created bare repository to the local system as a remote repository. Additionally, it is a standard convention that the users name this as “production” to specify the working environment. Similarly, for deployment in multiple systems, it can be termed as “live,” “staging,” or “test.”
$ cd ~/path/to/working-copy/
$ git remote add production firstname.lastname@example.org:project.git
Note: There must be a correspondence between the name of the bare repository and the remote repository made locally. While using Tower or similar apps, a newly added remote repository resides in the sidebar under “Remotes.”
The last step is to push the master branch to the production server. While using Tower, there is an option to drag and drop the master branch to the production remote.
$ git push production master
Finally, the users can build a development machine by following the above steps to show the committed changes immediately.
No one can deny the importance of automating the crucial phases in the modern world’s development cycle. That is why there are countless solutions to it when it comes to automation in the CICD pipeline. Similarly, there are many ways to do it in GitHub, and git hooks also allow the users to automate their code in various ways. Since the automation needs may differ from developer to developer and the precise technology stack they are using, the solutions differ in providing personalized solutions.
Overall, the hooks’ utility is undeniable in the deployment automation because they help code deployment and maintain the code quality by rejecting the non-conformant commit messages.