加载中

GitHub, and the Git version control system it’s based on, are fantastic tools for managing and collaborating on projects – code-based or otherwise.

In this article, we’ll look at options for making Git and GitHub projects fit better into developer workflows, allowing for a smooth and hands-off deployment process.

I’ll break these options into the different types of toolsets available – which allow for options from automatically running tests and code checks to deploying your code to a server.

GitHub以及它所依赖的版本控制系统Git,绝对是非常出色的项目管理和协作的工具,不管项目是不是跟代码相关。

本文会讨论有哪些选项可以让Git和Github更好的融入项目的工作流当中,以实现平滑的自动化的过程。

我把这些选项划分到不同的工具集当中,这些集合包括自动运行测试,以及拉取代码部署到服务器上等等。

Why Do This?

With these automated processes up and running, you and your team can focus purely on coding, approving and merging code, rather than spending hours on deployments and repetitive tasks every time a new build or change is ready.

为何要这样做?

有了这些自动化过程的运行,你和你的团队就可以只关注单纯的编码以及代码的合并,而不是每次build的时候都要花费几个小时去重复的做部署这样的事情。

Disadvantages of Automation

The main problem with automatically deploying changes is that changes are automatically deployed. You have to trust your team and the code they write. This is why automatic deployment is typically paired with automated testing, and the tools presented below reflect this.

More from this author

Of course, it also means that any small issues are equally as quick to fix. Automation should be paired with communication. If pushing to a repository’s master branch can trigger live builds, it needs to be clear when this happens and who can make it happen.

The initial setup of an automation process can take some time to get right. It’s important to weigh up whether or not your team or workflow really needs it. Add up the amount of time you spend on testing and deploying new builds – and if it’s more than a few minutes each time, then it’s worth it.

自动化的缺点

自动化部署变化的主要问题是变化会自动地被部署。你必须信任你的团队以及他们写的代码。这就是为什么自动化部署和自动化测试的搭配成为典型,而下面提供的工具也反映了这一点。

来源于此文作者的更多内容

当然,这同样意味着仍和小问题也一样地被快速修复。自动化应该与沟通配合。如果推送到一个库的主分支会引发住建,需要明确,当这种情况发生时谁去做这件事情。

一个自动化的初始设置过程可能需要一些时间。因此权衡你的团队或者工作流程是否真正的需要它是一件重要的事情。把你们花在测试和部署新的构建上的时间加起来——如果是每次超过几分钟,那么它是值得的。

Git Hooks

Git has a suite of in-built hooks that can be used for automation, and these are often our first port of call for processing tasks after particular Git actions. These are divided into server- and client-side hooks.

Server-side hooks are for events such as listening to network operations – for example, when a repository receives a push. Client-side hooks are triggered on actions that occur on a developer’s machine, such as commits and merges.

There’s a full list of hooks in Git’s documentation. I’ll look at a couple here to get you started. Hopefully you’ll start to see how they may be useful in your own projects and current (manual) workflows. The hooks are files that can contain commands in any language the host system can run, allowing for a lot of power and flexibility.

pre-commit

This client-side hook runs before any other hook, and before any changes are committed. It’s a perfect place to run tests or other checks on your code.

Let’s add some basic JavaScript to our small project (and yes, there is an intentional mistake here):

document.onload = function() {
    alert("Hello World")
};

We’ll use JSHint to check the JavaScript for errors. (You can find installation instructions here.)

Rename hooks/pre-commit.sample to hooks/pre-commit, and change the contents of the file to this:

#!/bin/shjshint index.js

Try to commit the changes:

git commit -m "adding Javascript file"

You’ll see the following error message:

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

Add the missing semicolon and try again. The commit will now progress without any problems.

post-receive

This server-side hook triggers when a push to a remote Git repository completes. In this example, we checkout the latest version of a simple website into our webserver directory, effectively a (basic) deployment.

I have an existing website that consists of an index.html page – along with some other pages that we’ll use in later examples. You can create your own or use the repository set up here.

Clone the repository, specifying the --bare flag to create a repository that only consists of version control information and not our code base:

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

Now we’ll create our hook:

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

Add these lines to the file:

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

Note: these locations are relevant to an Ubuntu installation, so remember to change paths to suit your setup.

This command will checkout the current repository into the defined working directory, but without any version control data.

We need to make the hook executable:

chmod +x post-receive

On your local machine, clone the repository as normal, using your tool of choice, and add a new remote for the live server (remember to change the server details to your webserver and user details):

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

To deploy to our production server instead of the repository, enter:

git push prod master

If you look inside the var/www/html folder, you’ll find the index.html file automatically copied into your web folder.

If you’re using your own Git repository, you can have it located on the same server as your application, and deployments are now automated. If you’re using GitHub or another external Git service, then this hook has not completely automated your workflow, but rather has reduced it to one step. This can then be simplified further.

One option is using rsync or scp commands in the post-receive hook on GitHub. Another option – especially if your application needs a build process before going live (GitHub limits possible commands) – is to use the post-receive hook to trigger scripts on your application server that checks-out your code base from GitHub (with the -f option) and runs any other necessary commands. This is starting to get complicated, which leads nicely to our next set of tools.

Git Hooks(钩子)

Git内置了一套拓展框架叫做钩子(http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)用来处理自动化部署,并且这些钩子一般在被特定的Git事件(certain points)触发后被调用在我们的第一端口用来处理任务。钩子可以被分为服务器端钩子与客户端钩子。

服务器端是用于监听网络操作的事件 ——比如,当存储库接收推送后。而客户端挂钩的触发是因为开发者进行了操作,如提交和合并。

这是在Git文档中hooks的完整列表(http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)。在这里我开始介绍几个钩子。希望这能让你在自己当前手动部署的项目工作流程中中变得非常有用。Hooks可以在任何语言的项目部署中运行,强大而灵活。

  pre-commit

此这个钩子运行在其他所有钩子之前,并且在更改提交之前。可以用来在提交前检查代码错误。

我们在这里写一个JavaScript的小项目说明(当然,我故意留了你可以找到的bug)。

重命名hooks/pre-commit.sample 为 hooks/pre-commit,并进行如下测试命令,以这样的内容:

#!/bin/shjshint index.js

试着提交这个变动:

git commit -m "adding Javascript file"

你可以看到报错信息:

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

添加缺少的分号后重新提交,不再报错。

post-receive

当推送远程Git仓库完成时,服务器端的该钩子触发。在这个例子中,我们推出一个简单的网站的最新版本到你的Web服务器目录,实际上是一个(最基本的)部署。
我有一个现有的网站包含有一个index.html页 - 以及我们在后面的例子将使用的其他网页。你也可以创建自己的,使用在这里设立仓库。
克隆仓库,通过--bare来创建一个只包含版本控制信息的存储库,而不是我们的代码仓库:

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

现在我们添加钩子:

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

添加这些到文件中:

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

注意:这些路径是基于Ubuntu环境下完成,所以记得要改变路径,以满足你的路径。
该命令将推出当前仓库到定义的工作目录,但不检查任何版本控制数据。

chmod +x post-receive

小贴士:这些位置与Ubuntu的安装路径相关,所以一定记得要改变路径,以满足您的设置。该命令将检查当前的存储库到定义的工作目录,但没有任何版本控制数据。

将文件添加可执行的权限:


chmod +x post-receive
在你的本地端,像平时一样克隆这个库,使用你选择的工具,并添加一个新的远程的实时服务器(记得更改服务器的详细信息到你的Web服务器和用户的详细信息):


git remote add prod ssh://user@domain.com/var/repo/GitHub-Auto-Deploy.git
要部署到我们生产环境下的服务器来替代仓库,输入以下命令:


git push prod master
你可以ls一下服务器的 var/www/html 目录,可以看到index.html文件已经被自动拷贝进你的web文件夹内啦。

如果你使用的是自己的Git仓库,你可以把它配置在同一台服务器上的应用,并实现自动化部署。如果你使用的是GitHub上或其他外部Git的服务,那么这个钩子还没有完全自动化,但它已经降到了一步。这可以进一步简化。

GitHub的post-receive 钩子中有一个可以使用reync或scp的选项。这是另外的一种选择——特别是当你的应用需要构建时(GitHub限制了可能的命令)——是使用post-receive 钩子来触发,然后使用-f选项可以检查出从GitHub的代码库的应用程序服务器上的脚本和运行其他一些必要的命令。这个时候,自动化部署开始变得复杂起来,我们不得不使用下一套工具来更好的完成。

Autodeployment Directly from GitHub

GitHub has its own documentation for automating deployments to integration platforms, some of which are hosting providers.

To be honest, most of the documentation I checked out was incorrect, inaccurate or unhelpful, so I did some searching to link to official documentation on some popular hosting providers, and for any others I suggest you use the post-receive or continuous integration methods:

从 GitHub 直接自动部署

GitHub 有它自己的文档来自动化部署到集成平台,这里包括一些托管提供商。

老实说,大部分文档都有些错误,不准确或者没有起到作用, 在一些主流的主机提供商那儿,我做了一些搜索链接到官方文档,对于其他一些提供商,我建议你使用 post-receiveor 持续集成的方法:

Continuous Integration (CI) Services

There are a myriad services available that can watch your GitHub repos for changes and not only then deploy them for you, but also perform other functions such as running tests and build processes for you.

Moving to a new and more complex example, we could use CI to automate the build process of a project. Firstly, pulling the Master branch of a repository, triggering a bash script to run the build and deploy process, and then tweeting about the updates. The CI and web services could be on the same server or on different servers depending on your preference.

Let’s take a quick look at some of the most popular.

持续集成(CI)服务

有许多无数的能够查看 GitHub 项目回购变更协议的应用服务,不仅能够为你部署,而且能够执行其他功能,诸如为你运行测试和构建过程。

一旦你移动到一个新的和更复杂的实例时,我们可以使用 CI

自动化构建项目过程。首先,拉伸一个存储库的 Master 分支,然后触发一个运行构建的 bash 脚本,并且部署流程以及对微博更新。CI 与 web 服务能够在同一台服务器上或者在不同的服务器上运行,这一切都取决于你的偏好。

让我们迅速一览其最受欢迎的部分吧。

Jenkins

You’ll need to set up your own Jenkins server, which means you get complete control, but it requires maintenance. Fortunately, it supports many platforms, including Docker if you just want to experiment first.

Jenkins achieves most of its functionality with plugins, and thanks to its age, open-source nature and popularity, it has a lot of plugins. For example, there are plugins for Git, GitHub and Twitter.

Jenkins requires a lot of configuration, and sometimes piecing together the instructions you need to construct your desired workflow can require a lot of research.

Jenkins

你需要搭建你自己的 Jenkins 服务器,这意味着你可以完全地控制它,但必须要对它进行维护。幸运的是,它提供了多平台支持,如果你只是想要先简单尝试一下的话,这些支持也包括了 Docker。

Jenkins 使用插件实现了自己的大部分功能,并且由于其年代久远、开源的性质以及普及度很广,它拥有很多的插件。例如,有一些 GitGitHub 和 Twitter 的相关插件。

Jenkins 需要大量的配置,而且有时,若想要将你需要的指令组合到一起来构造你所需的工作流程,可能需要大量的研究。

Travis

Again, the instructions for integrating Travis with GitHub are out of date in GitHub’s documentation. It’s even more simple now: read the Travis docs to find out more.

Travis doesn’t require any hosting or server setup, so if you’re keen to try CI without investing too much setup time, it’s a good starting point. However, extending it beyond its (comprehensive) default integrations will involve some extra config work. For example, Tweeting requires access to webhooks.

Travis has a habit of being slow to notice updates in your repos – especially in its own configuration file. These issues can then be hard to solve, as you have no access to the Travis server itself.

Travis

此外,在 GitHub 文档中,使用 GitHub 的 Travis 集成指令已经过时。现在,它更简单:阅读找出更多的 Travis 文档。

Travis 不需要任何主机与服务器设置,因此你无需投入太多的精力,就可以保持和试用CI,这是一个很好的起点。不过,扩展超出(综合)默认的集成将涉及到一些额外的配置工作。比如,微博请求对 webhooks 的访问。

在回购中,你会注意到 Travis-- 特别是在配置自己的文件中,它有一个习惯,就是更新太慢。当你本身没有对 Travis 服务器进行访问时,那么这些问题就难以解决。

Other Commercial Services

Continuous integration is increasingly popular, so there’s been a plethora of new services and applications – many released by the creators of tools you may already be using, and which will fit snugly into existing toolchains and workflows. Here are some examples:

其他商业服务

持续集成已经日益流行了,所以已经有了非常多的新的服务和应用程序 – 很多是通过你可能已经在使用的工具的创作者释出的,并且将很和谐的融入到现有的工具链和工作流程当中。这里有些例子:

Wrap Up

Hopefully this brief introduction has clarified a few things for you regarding how this kind of deployment works. We’ve certainly come a long way from the days of FTPing your files to your server!

If you have any questions about the processes described above, please let me know in the comments.

Tags: auto deployment, continous deployment, git, git hooks, github, server side hooks

总结

希望这篇简要的介绍已经为你阐明了关于这种部署方式是如何工作的一些事情。当然,我们还有很长的路来实现通过 FTP 将你的文件传到你的服务器!

如果你对上述流程有任何疑问,请在评论区中让我知晓。

Tags: auto deployment, continous deployment, git, git hooks, github, server side hooks

返回顶部
顶部
返回顶部
顶部