将项目从 GitHub 部署到服务器 已翻译 100%

oschina 投递于 2016/01/18 15:41 (共 10 段, 翻译完成于 02-01)
阅读 11873
收藏 127
11
加载中

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.

已有 1 人翻译此段
我来翻译

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.

已有 2 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译

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:

已有 1 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译

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:

已有 1 人翻译此段
我来翻译

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

已有 1 人翻译此段
我来翻译
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(6)

Bugzhang
Bugzhang

引用来自“kennedy”的评论

@Bugzhang
"我会注释一对情侣在这里让你开始。" -->“在这里我开始介绍几个钩子”
"通过指定--bear标记" --> "--bare"
"但没有任何版本控制数据" --> "但不检查任何版本控制数据"

引用来自“Bugzhang”的评论

谢谢前辈指点,第一次做翻译,多有失误,望谅解~O(∩_∩)O

引用来自“OceanJaya”的评论

我会注释一对情侣在这里让你开始 哈哈哈哈哈暴露了。。
我是内天晚上太瞌睡,3点多在床上翻译的,打字打错了啊,第二天醒来自己改了一部分,但没改完。。。。。别黑窝。
azheng
azheng
我觉得吧, 些个shell脚本 弄个页面, 点一下就自动 拉代码 编译 部署 启动, 这样不是很好吗
OceanJaya
OceanJaya

引用来自“kennedy”的评论

@Bugzhang
"我会注释一对情侣在这里让你开始。" -->“在这里我开始介绍几个钩子”
"通过指定--bear标记" --> "--bare"
"但没有任何版本控制数据" --> "但不检查任何版本控制数据"

引用来自“Bugzhang”的评论

谢谢前辈指点,第一次做翻译,多有失误,望谅解~O(∩_∩)O
我会注释一对情侣在这里让你开始 哈哈哈哈哈暴露了。。
Bugzhang
Bugzhang

引用来自“kennedy”的评论

@Bugzhang
"我会注释一对情侣在这里让你开始。" -->“在这里我开始介绍几个钩子”
"通过指定--bear标记" --> "--bare"
"但没有任何版本控制数据" --> "但不检查任何版本控制数据"
谢谢前辈指点,第一次做翻译,多有失误,望谅解~O(∩_∩)O
kennedy
kennedy
@Bugzhang
"我会注释一对情侣在这里让你开始。" -->“在这里我开始介绍几个钩子”
"通过指定--bear标记" --> "--bare"
"但没有任何版本控制数据" --> "但不检查任何版本控制数据"
花儿笑弯了腰
花儿笑弯了腰
沙发
返回顶部
顶部
返回顶部
顶部