部署git服务器_服务器端Git挂钩的一键式应用程序部署

部署git服务器

概要 (Synopsis)

This post shows the user how to deploy a simple website using no more than a git post-receive hook. It covers just enough background information so that the reader can go further and expand their knowledge as their time permits.

这篇文章向用户展示了如何仅使用git post-receive钩子来部署一个简单的网站。 它仅涵盖了足够的背景信息，因此读者可以在时间允许的情况下走得更远并扩大知识面。

一键式部署 (One-Click Deploy)

How often do we say preach the mantra of one click deployment? Every Project? Every Day? Every Commit? If we’re anything alike, you’ll have readily identified with one or more of these. We've all been in roles or had projects where we've had to jump through a number of hoops to get our application deployed on one or more environments.

我们多久讲一次“一键式部署”的口号？ 每个项目？ 每天？ 每次提交？ 如果我们有任何相似之处，您将很容易地识别出其中的一个或多个。 我们都曾担任过多个角色或从事过一些项目，我们不得不跳过许多难题才能将我们的应用程序部署到一个或多个环境中。

We know that ultimately it's a distraction from what we're best at: application design and development. We know we should be focused on other areas, such as architecture, testing, and design. Yet we get repeatedly bogged down in the minutiae of copying files, running scripts and so on. We get repeatedly bogged down in tasks which should always be automated.

我们知道，最终这会分散我们的专长： 应用程序设计和开发 。 我们知道我们应该专注于其他领域，例如架构 ， 测试和设计 。 但是，我们一再陷入无法复制文件，运行脚本等细节的困境。 我们一再陷入停滞不前的任务，这些任务应始终自动化 。

Perhaps you're familiar with one of the following scenarios:

也许您熟悉以下情况之一：

• Following a deploy checklist
  遵循部署清单
• SSH'ing to a remote box and running a set of scripts
  SSH到远程服务器并运行一组脚本
• Manually FTP'ing files to a remote server
  手动通过FTP将文件传输到远程服务器

I hope you're not doing the last one…

希望您不要做最后一个…

For years I talked the talk but didn't walk the walk. But in recent times, my life, my time, my family and friends became too important to continue that way. They became too important to waste time, spending countless hours, deploying code. Perhaps you're the same. If you are, this article series is for you.

多年以来，我一直在谈论这个话题，但没有走。 但是最近，我的生活，我的时间，我的家人和朋友变得非常重要，无法继续这样做。 它们变得太重要了，以至于无法浪费时间，花费无数时间，部署代码。 也许你是一样的。 如果您愿意，那么本系列文章适合您。

Recently I read Tim Boronczyk’s Git Hooks for Fun and Profit post here on Sitepoint and thought what if. I read the manual on using git hooks and took inspiration from Tim's post, thinking that there must be a way to automate deployment of a remote web app with them.

最近我读到添Boronczyk的混帐挂钩的乐趣和利润后这里Sitepoint并认为如果什么 。 我阅读了有关使用git hook的手册，并从Tim的帖子中学到了灵感，认为必须有一种方法可以自动使用它们来部署远程Web应用程序。

I set myself a simple, clear, goal:

我为自己设定了一个简单，明确的目标：

I will only need to run git push and the deployment will be taken care of, with no further involvement from me.

我只需要运行git push即可完成部署工作，而无需我进一步参与。

Friends looked at me a bit dubiously when I talked about it; but I was inspired. Justifiably, at this point, you may be wondering, why not just use a Continuous Integration (CI) server, such as Jenkins or Hudson, or a service like codeship.io? That's a good question, and if you thought it, points for doing so. Many don't.

当我谈论它时，朋友们有点怀疑地看着我。 但我受到启发。 有道理，在这一点上，您可能想知道，为什么不只使用诸如Jenkins或Hudson之类的持续集成(CI)服务器，还是诸如codeship.io之类的服务？ 这是一个很好的问题，如果您认为的话，这样做很重要。 许多人没有 。

Why not use one? Well as Beth Tucker-Long said in her talk at PHPUK last year, not all needs are so complex or sophisticated, or can justify the implementation costs.

为什么不使用一个？ 正如贝丝·塔克龙(Beth Tucker-Long) 去年在PHPUK的演讲中所说的那样 ，并非所有需求都如此复杂或复杂，或者可以证明实施成本合理。

So in today's post, we’re starting a series looking at how git hooks can help you implement simple and effective deployment processes. Today’s is the simplest of the lot.

因此，在今天的帖子中，我们将开始一系列研究git hooks如何帮助您实现简单有效的部署过程的系列。 今天是最简单的。

如何运作？ (How Will It Work?)

It consists of 3 parts:

它包括三个部分：

1. A working repository
   工作库
2. A remote, bare, repository
   远程的裸仓库
3. A working directory (your deployed site or test branch)
   工作目录(您部署的站点或测试分支)

We'll develop our application as normal, in our local working directory, and push to a remote as we normally would (e.g. Github, BitBucket etc). The remote repository though won't be a standard development repository. It needs to be what's called a bare repository, which the git scm book describes as:

我们将在本地工作目录中正常开发应用程序，并像往常一样推送到远程(例如Github ， BitBucket等)。 远程存储库虽然不是标准的开发存储库。 它必须是所谓的裸存储库 ， git scm书描述为：

a repository that doesn’t contain a working directory

不包含工作目录的存储库

If this seems a little confusing, that's perfectly normal. I did a lot of reading as I came to understand this setup. During that research I found this quote from bitflop.com which explains it quite succinctly.

如果这看起来有些混乱，那是完全正常的。 当我开始了解这种设置时，我做了很多阅读。 在研究过程中，我从bitflop.com找到了这句话，它非常简洁地解释了它。

In Git you should only use a "bare" repository to clone and pull from, and push to. It doesn't have a checked out tree, so it just does what the "server" notionally does in a centralized VCS – records commits, branches, etc when you push to it, and gives you the latest versions when you clone or pull from it.

在Git中，您仅应使用“裸”存储库来克隆，提取和推送到。 它没有检出的树，因此它只执行集中式VCS中“服务器”的名义上的工作–在推送到树中时记录提交，分支等，并在您克隆或从中拉取时提供最新版本它。

So in our bare repository we won't be able to edit files and make changes. It's purely there for us to push our latest changes to and for those changes to be deployed from, to our working directory. If it helps, use the image below to conceptualize it.

因此，在我们的裸仓库中，我们将无法编辑文件和进行更改。 纯粹是为了我们将最新更改推向工作目录，并将这些更改从其部署到我们的工作目录。 如果有帮助，请使用下面的图片将其概念化。

设置远程存储库 (Setting Up the Remote Repository)

For the purposes of this article, I'm going to assume you're using a Linux (Debian) server, and that the remote repository will be stored in /opt/git. We'll call it simpleapp.git. I've added .git at the end because it seems to be the accepted convention.

出于本文的目的，我将假设您使用的是Linux(Debian)服务器，并且远程存储库将存储在/opt/git 。 我们将其称为simpleapp.git 。 我在末尾添加了.git ，因为它似乎已被接受。

Using these assumptions, we run the following commands, to setup the remote repository:

使用这些假设，我们运行以下命令来设置远程存储库：

$ mkdir -p /opt/git
$ cd /opt/git
$ git clone --bare simpleapp simpleapp.git
Initialized empty Git repository in /opt/git/simpleapp.git/

When this is finished, if you ls the directory, you'll notice that it contains what would normally be stored in the .git directory. This is perfectly fine as the working directory in this case is, effectively, the deployed directory.

完成这些步骤后，如果您ls的目录，你会发现它包含什么通常被存储在.git目录。 这很好，因为在这种情况下，工作目录实际上是已部署目录。

接收后挂钩 (The Post-Receive Hook)

With the remote repository setup, we next add a git post-receive hook. I've supplied a sample one in post-receive.sh:

通过远程存储库设置，我们接下来添加一个git post-receive钩子。 我在post-receive.sh提供了一个示例：

#!/bin/sh
# 
## store the arguments given to the script
read oldrev newrev refname

## Where to store the log information about the updates
LOGFILE=./post-receive.log

# The deployed directory (the running site)
DEPLOYDIR=/var/www/html/simpleapp

##  Record the fact that the push has been received
echo -e "Received Push Request at $( date +%F )" >> $LOGFILE
echo " - Old SHA: $oldrev New SHA: $newrev Branch Name: $refname" >> $LOGFILE

## Update the deployed copy
echo "Starting Deploy" >> $LOGFILE

echo " - Starting code update"
GIT_WORK_TREE="$DEPLOYDIR" git checkout -f
echo " - Finished code update"

echo " - Starting composer update"
cd "$DEPLOYDIR"; composer update; cd -
echo " - Finished composer update"

echo "Finished Deploy" >> $LOGFILE

This script, written in bash, will be fired off after the push is received by the remote repository. It manages the entire deployment process for us, consisting of the following steps:

远程存储库收到推送后，将以bash编写此脚本。 它为我们管理整个部署过程，包括以下步骤：

1. Update the code in the deployed directory, to the latest version
   将部署目录中的代码更新为最新版本

2. Run composer install, ensuring we have all dependencies in place

   运行composer install ，确保我们具有所有依赖项

Let's look at it piece by piece:

让我们逐个看一下：

read oldrev newrev refname

Here we store the three arguments passed to the post-receive script when it's called. These are:

在这里，我们存储调用时传递给后接收脚本的三个参数。 这些是：

• The previous commit SHA1 hash
  先前的提交SHA1哈希
• The latest commit SHA1 hash
  最新提交SHA1哈希

• The refname (containing branch information)

  refname (包含分支信息)

This helps track what's being deployed and to rollback should you need to do so. This script doesn't handle a rollback however.

这有助于跟踪正在部署的内容，并在需要时进行回滚。 但是，此脚本无法处理回滚。

LOGFILE=./post-receive.log
DEPLOYDIR=/var/www/html/simpleapp

Next we setup a variable to log the output of the deployment and the deployment directory.

接下来，我们设置一个变量以记录部署的输出和部署目录。

echo -e "Received Push Request at $( date +%F )" >> $LOGFILE
echo " - Old SHA: $oldrev New SHA: $newrev Branch Name: $refname" >> $LOGFILE
echo "Starting Deploy" >> $LOGFILE

Here we're logging when a push request was received and the details about it. That way, should we need to debug, we have relevant information to hand and a quick message to say that we're starting the deploy process.

在这里，我们记录接收到推送请求的时间及其详细信息。 这样，如果我们需要调试，我们将掌握相关信息，并提供一条简短的消息说我们正在开始部署过程。

echo " - Starting code update"
GIT_WORK_TREE="$DEPLOYDIR" git checkout -f
echo " - Finished code update"

Here we tell git where the working tree is, and instruct git to checkout the latest copy of the code to that directory, removing any changes which may have manually been made.

在这里，我们告诉git工作树在哪里，并指示git将代码的最新副本检出到该目录，删除可能手动进行的任何更改。

echo " - Starting composer update"
cd "$DEPLOYDIR"; composer update; cd -
echo " - Finished composer update"

Now that the code's updated, as I use composer for dependency management, we run composer update as there may have been a change to composer.json changing the application's dependencies.

现在，代码的更新，因为我用作曲家依赖管理，我们运行composer update为有可能已被更改composer.json改变应用程序的依赖。

echo "Finished Deploy" >> $LOGFILE

The last step is indicating that the deploy's now complete. You'd likely do a lot more than this in a standard project, including:

最后一步表明部署现已完成。 在标准项目中，您可能会做的比这更多，包括：

• Clearing and pre-warming cache directories
  清除和预热缓存目录
• Running database migrations
  运行数据库迁移
• Running unit & regression tests
  运行单元和回归测试
• Checking permissions on key directories
  检查关键目录的权限

However, this is a simple example and I don't want to distract you from the main aim. In the hooks directory, create a new file called post-receive and add the contents of post-receive.sh. You should only need to change one variable, DEPLOYDIR.

但是，这是一个简单的示例，我不想分散您的主要目标。 在hooks目录中，创建一个名为post-receive的新文件，并添加post-receive.sh的内容。 您只需要更改一个变量DEPLOYDIR 。

Change it to suit your needs, and don't forget to make the file executable, otherwise it won't run. If you're not familiar with how to do that, it's as follows:

根据您的需要进行更改，并且不要忘记使该文件可执行，否则它将无法运行。 如果您不熟悉该操作，请执行以下操作：

chmod +x post-receive

Git用户 (The Git User)

Whilst on the remote server, there's one step left to go, the git user. This is the user who will manage the process, and who we'll authenticate as. So if it doesn't already exist, run the following command to create it:

在远程服务器上，还有git用户。 该用户将负责管理流程，我们将以此身份进行身份验证。 因此，如果尚不存在，请运行以下命令来创建它：

sudo adduser git

After that, you need to add your public key to the authorized_keys file in the .ssh directory in the git user's home directory.

之后，您需要将公共密钥添加到git用户主目录中.ssh目录中的authorized_keys文件中。

Note: If you don't have one or aren't familiar with them, this excellent, short guide from GitHub steps you through creating one.

注意：如果您不熟悉或不熟悉它们，则此 GitHub上的优秀简短指南将指导您逐步创建一个。

The simplest way to copy the public key is likely copying the contents between terminal sessions. So copy the contents of ~/.ssh/id_rsa.pub whether via scp or terminal session to your remote server and add them to the remote authorized_keys file.

复制公钥的最简单方法是在终端会话之间复制内容。 因此，通过scp或终端会话将〜/ .ssh / id_rsa.pub的内容复制到远程服务器，然后将其添加到远程authorized_keys文件中。

Then from your local machine, test that you can now ssh to the remote box by running the following command, substituting remoteserver as appropriate.

然后在本地计算机上运行以下命令，测试您现在可以通过ssh进入远程remoteserver并适当地替换remoteserver 。

ssh git@remoteserver

All being well, you're not prompted for a username and password. Next, ensure that the git user has proper permissions on both the /opt/git/simpleapp directory and the deploy directory.

一切都很好，不会提示您输入用户名和密码。 接下来，确保git用户对/opt/git/simpleapp目录和deploy目录都具有适当的权限。

添加远程存储库 (Adding The Remote Repository)

After that, we're pretty much finished. In your working directory, run the following command to add the new remote repository:

之后，我们差不多完成了。 在您的工作目录中，运行以下命令以添加新的远程存储库：

git remote add test git://remoteserver/opt/git/simpleapp.git

Then, verify that it's in place with the following:

然后，使用以下命令验证它是否就位：

git remote

With that in place, all we need to do is then start developing our application and push as required.

完成此操作后，我们要做的就是开始开发应用程序并根据需要进行推送。

结论 (In Conclusion)

I understand that it's a lot to take in as it's quite an involved process, at least at first. However, like Linux, once you've got everything up and running, the majority of the work's over.

我了解，这是一个非常复杂的过程，因此至少需要一开始就需要大量的工作。 但是，像Linux一样，一旦一切就绪并开始运行，大部分工作就结束了。

What do you think? Let me know what else you'd like to see. I hope this article's shown you that it's both possible and straight-forward to auto-deploy.

你怎么看？ 让我知道您还想看到什么。 我希望本文向您显示自动部署既可行又直接。

Have you already done this? Have you approached it a different way? Can you do better? Give me your thoughts in the comments.

你已经做到了吗？ 您是否采用了其他方法？ 你能做得更好吗？ 在评论中告诉我您的想法。

翻译自: https://www.sitepoint.com/one-click-app-deployment-server-side-git-hooks/

部署git服务器