本地部署github服务器_从GitHub部署到服务器

本地部署github服务器

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

GitHub及其基于的Git版本控制系统是用于管理和协作项目(基于代码或其他代码)的出色工具。

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.

在这篇文章中，我们将看看制作Git和GitHub的项目选择更好的适应开发商的工作流程，从而为顺利和放手部署过程。

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.

我将这些选项分解为可用的不同类型的工具集-允许使用从自动运行测试和代码检查到将代码部署到服务器的选项。

为什么这样做？ (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.

随着这些自动化过程的启动和运行，您和您的团队可以完全专注于编码，批准和合并代码，而不必在每次准备好新的构建或变更时就花费大量时间进行部署和重复性任务。

自动化的缺点 (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.

自动部署变更的主要问题是自动部署变更。 您必须信任您的团队和他们编写的代码。 这就是为什么自动部署通常与自动测试结合使用的原因，下面介绍的工具反映了这一点。

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.

当然，这也意味着任何小问题同样可以Swift解决。 自动化应与通讯配合使用。 如果推送到存储库的master分支可以触发实时构建，则需要清楚何时发生这种情况以及谁可以实现。

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.

Git有一套可用于自动化的内置挂钩 ，这些挂钩通常是我们在执行特定Git动作后处理任务的第一站。 这些分为服务器和客户端挂钩。

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.

在Git的文档中有钩子的完整列表。 我将在这里看看几个，以帮助您入门。 希望您将开始看到它们在您自己的项目和当前(手动)工作流中的有用性。 挂钩是可以包含主机系统可以运行的任何语言的命令的文件，从而具有强大的功能和灵活性。

pre-commit (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):

让我们在我们的小型项目中添加一些基本JavaScript(是的，这里有一个故意的错误)：

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

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

我们将使用JSHint来检查JavaScript中的错误。 (您可以在此处找到安装说明 。)

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

将hooks/pre-commit.sample重命名为hooks/pre-commit ，并将文件内容更改为此：

#!/bin/sh
jshint 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 (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.

当对远程Git存储库的推送完成时，将触发此服务器端挂钩。 在此示例中，我们将简单网站的最新版本检出到我们的webserver目录中，实际上是(基本)部署。

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.

我有一个现有的网站，该网站包含index.html页面以及我们将在以后的示例中使用的其他一些页面。 您可以创建自己的数据库或使用此处设置的存储库 。

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

克隆存储库，指定--bare标志以创建仅由版本控制信息而不由我们的代码库组成的存储库：

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/hooks
vi post-receive

Add these lines to the file:

将这些行添加到文件中：

#!/bin/sh
git --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.

注意：这些位置与Ubuntu安装有关，因此请记住更改路径以适合您的设置 。

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):

在本地计算机上，使用您选择的工具正常克隆存储库，并为实时服务器添加一个新的远程服务器(请记住，将服务器详细信息更改为您的Web服务器和用户详细信息)：

git remote add prod ssh://[email protected]/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.

如果查看var/www/html文件夹，您会发现index.html文件自动复制到您的Web文件夹中。

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.

如果您使用自己的Git存储库，则可以将其与应用程序放在同一服务器上，并且部署现在是自动化的。 如果您使用的是GitHub或其他外部Git服务，则此挂钩尚未完全自动化您的工作流程，而是将其简化为一个步骤。 然后可以进一步简化。

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.

一种选择是在GitHub上的post-receive挂钩中使用rsync或scp命令。 另一种选择(尤其是如果您的应用程序在上线之前需要构建过程(GitHub限制了可能的命令))是使用post-receive挂钩来触发应用程序服务器上的脚本，该脚本从GitHub检出您的代码库(使用-f选项)并运行任何其他必要的命令。 这开始变得越来越复杂，这很好地引出了我们的下一组工具。

直接从GitHub自动部署 (Autodeployment Directly from GitHub)

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

GitHub拥有自己的文档，用于自动化对集成平台的部署，其中一些托管服务提供商。

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:

老实说，我检出的大多数文档都不正确，不准确或无用，所以我做了一些搜索以链接到一些受欢迎的托管服务提供商的官方文档，对于其他任何文档，我建议您使用post-receive或持续集成的方法：

• Heroku

  Heroku

• AWS

  AWS

• Azure

  蔚蓝

持续集成(CI)服务 (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.

有许多服务可以监视您的GitHub存储库中的更改，不仅可以为您部署它们，还可以为您执行其他功能，例如运行测试和构建流程。

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.

转到一个新的更复杂的示例，我们可以使用CI来自动化项目的构建过程。 首先，拉出存储库的Master分支，触发bash脚本以运行构建和部署过程，然后在推特上发布更新。 CI和Web服务可以位于同一服务器上，也可以位于不同服务器上，具体取决于您的偏好。

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

让我们快速浏览一些最受欢迎的。

詹金斯 (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服务器，这意味着您可以完全控制，但是需要维护。 幸运的是，如果您想先进行实验，它支持许多平台，包括Docker。

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通过插件实现了其大部分功能，并且由于其年代久远，开放源代码的性质和受欢迎程度，它拥有许多插件。 例如，有用于Git ， GitHub和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需要大量配置，有时将需要的指令拼凑起来以构建所需的工作流程可能需要大量的研究。

特拉维斯 (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与GitHub集成的说明在GitHub文档中已过时。 现在，它变得更加简单：阅读Travis文档以了解更多信息。

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不需要任何托管或服务器设置，因此如果您想尝试CI而又不花费太多的设置时间，那么这是一个很好的起点。 但是，将其扩展到其(全面的)默认集成之外将涉及一些额外的配置工作。 例如， 推特需要访问webhook。

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习惯于缓慢地注意到仓库中的更新，尤其是在其自己的配置文件中。 这些问题可能很难解决，因为您无权访问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:

持续集成变得越来越流行，因此出现了许多新服务和应用程序-许多服务或应用程序是由您可能已经在使用的工具的创建者发布的，并且将紧贴现有的工具链和工作流程。 这里有些例子：

• https://buddy.works/

  https://buddy.works/

• https://www.atlassian.com/software/bamboo/

  https://www.atlassian.com/software/bamboo/

• https://www.jetbrains.com/teamcity/

  https://www.jetbrains.com/teamcity/

• https://codeship.com/

  https://codeship.com/

• https://circleci.com/

  https://circleci.com/

• https://saucelabs.com/

  https://saucelabs.com/

• https://about.gitlab.com/gitlab-ci/

  https://about.gitlab.com/gitlab-ci/

• http://deploybot.com/

  http://deploybot.com/

结语 (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!

希望此简短介绍为您澄清了有关这种部署如何工作的一些信息。 从将文件通过FTP传输到服务器的日子以来，我们当然已经走了很长一段路！

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

如果您对上述流程有任何疑问，请在评论中让我知道。

翻译自: https://www.sitepoint.com/deploying-from-github-to-a-server/

本地部署github服务器