Deploy the project from GitHub to the server

Deploy the project from GitHub to the server

GitHub and the version control system Git it relies on are definitely excellent tools for project management and collaboration, regardless of whether the project is related to code or not.

This article will discuss the options to better integrate Git and Github into the project workflow to achieve smooth automation.

I divided these options into different tool sets, including automatic test running and code pulling to deploy on the server.

Why?

With the execution of these automated processes, you and your team can focus only on simple code and code merging, instead of repeatedly deploying such a task every build, it takes several hours.

Disadvantages of Automation

The main problem with automated deployment changes is that changes are automatically deployed. You must trust your team and the code they write. This is why the combination of automated deployment and automated testing has become a typical example, and the tools provided below also reflect this.

More from The author of this article

• Blink (1), a Programmable Indicator for All Developer Needs

• The Next Full Stack Language? Server-side Swift with Perfect

Of course, this also means that it is still quickly fixed as a small problem. Automation should work with communication. If the master branch pushed to a database is created, it must be clear who will do this when this happens.

An automated initial setup process may take some time. Therefore, it is important to weigh whether your team or workflow really needs it. Add up the time you spend on testing and deploying new builds-if it takes more than a few minutes each time, it is worthwhile.

Git Hooks (Hook)

Git built in a set of extension frameworks called hooks (http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) to handle automated deployment, and these hooks are generally used by specific Git events (certain points) after the trigger, it is called on our first port to process the task. Hooks can be divided into server-side hooks and client-side hooks.

The server is an event used to listen for network operations-for example, when the repository receives the push. The client hook is triggered by operations performed by the developer, such as submitting and merging.

This is the complete list of hooks (http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) in the Git document ). I will comment out a couple here for you to start. We hope this will make it very useful for you in the current manual deployment project workflow. Hooks can run in project deployment in any language, which is powerful and flexible.

Pre-commit

This hook runs before all other hooks and before the changes are submitted. It can be used to check for code errors before submission.

Here we will write a small JavaScript project description (of course, I intentionally leave the bug you can find ).

Rename hooks/pre-commit.sample to hooks/pre-commit and run the following test command:

#! /Bin/shjshint index. js

Try to submit this change:

Git commit-m "adding Javascript file"

You can see the error message:

Index. js: line 5, col 25, Missing semicolon.1 error

Add a missing semicolon and submit it again. No error is reported.

Post-receive

This hook is triggered on the server when the remote Git repository is pushed. In this example, we release a simple latest version of the website to your Web Server Directory, which is actually a (basic) deployment.

I have a website containing an index.html page-and other web pages we will use in the following example. You can also create your own repository here.

Clone the repository and create a repository containing only version control information by specifying the -- bear tag, instead of our code repository:

Git clone -- bare https://github.com/sitepoint-editors/GitHub-Auto-Deploy.git GitHub-Auto-Deploy.git

Now we add a HOOK:

Cd GitHub-Auto-Deploy.git/hooksvi post-receive

Add these to the file:

#! /Bin/shgit -- work-tree =/var/www/html -- git-dir =/var/repo/GitHub-Auto-Deploy.git checkout-f

Note: These paths are based on the Ubuntu environment, so remember to change the path to meet your path.

This command will launch the current repository to the defined working directory, but there is no version control data.

Modify the file attributes to make them executable:

Chmod + x post-receive

TIPS: these locations are related to the Ubuntu installation path, so be sure to change the path to meet your requirements. This command checks the current repository to the defined working directory without any version control data.

Add executable permissions to files:

Chmod + x post-receive

On your local end, clone the library as usual and use the tool you choose, and add a new remote real-time server (remember to change the server details to your Web server and user details ):

Git remote add prod ssh: // user@domain.com/var/repo/GitHub-Auto-Deploy.git

To deploy a server in our production environment to replace the repository, run the following command:

Git push prod master

You can ls the var/www/html directory on the server to see that the index.html file has been automatically copied to your web folder.

If you are using your own Git repository, you can configure the application on the same server and implement automatic deployment. If you are using GitHub or other external Git services, this hook is not fully automated yet, but it has been reduced to one step. This can be further simplified.

The post-receive hook on GitHub has an option that can use either reync or scp. This is another option -- especially when your application needs to be built (GitHub limits possible commands) -- it is triggered using the post-receive hook, then, use the-f option to check the scripts on the application server from the GitHub code base and run other necessary commands. At this time, the automated deployment began to become complicated and we had to use the next tool for better implementation.

Direct automatic deployment from GitHub

GitHub has its own documentation to automate deployment to the integration platform, which includes some hosting providers.

Honestly, most of the documents are incorrect, inaccurate, or ineffective. In some mainstream host providers, I have made some search links to official documents. For other providers, we recommend that you use the post-receiveor continuous integration method:

• Heroku

• AWS

• Azure

CI Service

There are countless application services that can view the GitHub project repurchase and change agreement, not only for you to deploy, but also for other functions, such as running the test and build processes for you.

Once you move to a new and more complex instance, we can use CI

Automate the project building process. First, stretch the Master branch of a repository, then trigger a bash script to run the build, and deploy the process and update Weibo. It depends on your preferences that CI and web services can run on the same server or on different servers.

Let's take a quick look at the most popular part.

Jenkins

You need to build your own Jenkins server, which means you can control it completely, but you must maintain it. Fortunately, it provides multi-platform support. If you just want to give it a simple try, these support also includes Docker.

Jenkins uses plug-ins to implement most of its functions. Due to its long history, open-source nature and popularity, Jenkins has many plug-ins. For example, there are some plug-ins related to Git, GitHub, and Twitter.

Jenkins requires a lot of configuration, and sometimes, if you want to combine the instructions you need to construct the workflow you need, you may need a lot of research.

Distributed building and deployment of Jenkins-nodes

Jenkins details: click here
Jenkins: click here

Travis

In addition, in the GitHub documentation, the use of GitHub's Travis integration commands has expired. Now, it is simpler: Read and find out more Travis documents.

Travis does not need any host and server settings, so you don't need to invest too much energy to maintain and try CI, which is a good start point. However, additional configuration work will be involved in integration that extends beyond (Comprehensive) the default. For example, Weibo requests access to webhooks.

In the repurchase, you will notice that Travis-especially in the configuration of your own files, it has a habit of updating too slowly. When you do not access the Travis server, these problems are hard to solve.

Other Commercial Services

Continuous integration has become increasingly popular, so there are already a lot of new services and applications-many of which are released by creators of tools you may already use, in addition, it will be well integrated into the existing tool chain and workflow. Here are some examples:

• Https://buddy.works/
• Https://www.atlassian.com/software/bamboo/
• Https://www.jetbrains.com/teamcity/
• Https://codeship.com/
• Https://circleci.com/
• Https://saucelabs.com/
• Https://about.gitlab.com/gitlab-ci/
• Http://deploybot.com/

Summary

I hope this brief introduction has already clarified how this deployment method works. Of course, we still have a long way to upload your files to your server through FTP!

If you have any questions about the above process, please let me know in the comment area.

GitHub Tutorials:

Create a personal technical blog via GitHub

GitHub tutorials

Git tag management details

Git branch management

Git remote repository details

Git local Repository (Repository) Details

Git server setup and Client installation

Git Overview

Share practical GitHub tutorials

GitHub details: click here
GitHub: click here

Deploying from GitHub to a Server

This article permanently updates the link address: