您见过的最聪明的源代码库使用方法是什么? [英] What is the cleverest use of source repository that you have ever seen?

问题描述

这实际上源于我之前的问题，其中一个答案让我想知道人们如何以不同的方式使用 scm/repository 进行开发.

解决方案

预测试提交

之前(TeamCity，构建经理):

<块引用>

这个概念很简单，构建系统是您提交进入主干之间的障碍，只有在构建系统确定您的提交不会破坏事物之后，它才会允许将提交引入版本控制，其他开发人员将将该更改同步并集成到他们的本地工作副本中

之后(使用像 Git 这样的 DVCS，这是一个源代码库):

<块引用>

我与 Hudson 进行预测试提交的工作流程涉及三个独立的 Git 存储库:

• 我的本地仓库(本地)，
• 规范/中央存储库(来源)
• 和我的世界可读"(在防火墙内)存储库(公共).

对于预先测试的提交，我在世界可读的存储库上使用一个不断变化的分支，称为pu"(潜在更新).
在 Hudson 内部，我创建了一个作业，该作业轮询全球可读的存储库(公共)以了解pu"分支中的更改，并在推送更新时启动构建.

我从开始到起源的改变工作流程是:

* 黑客，黑客，黑客* 提交到本地/主题* git pup 公开* Hudson 民意调查 public/pu* Hudson 运行潜在更新作业* 测试失败?o 是:返工提交，再试一次o 否:继续* 变基到本地/主* 推送到原点/主站

<块引用>

使用这个预先测试过的提交工作流我可以将我的大部分测试需求卸载到构建系统的机器集群，而不是在本地运行它们，这意味着我可以花大部分时间编写代码而不是等待在编码迭代之间在我自己的机器上完成的测试.

<小时>

(变体)私人构建(David Gageot，Algodeal)

原理与上述相同，但构建是在与用于开发的工作站相同的工作站上完成的，但在克隆的存储库上:

<块引用>

如何不长期使用 CI 服务器，而不会因盯着本地构建而浪费的时间越来越长?

有了 git，小菜一碟.
首先，我们将工作目录git clone"到另一个文件夹.Git 复制非常.
下一次，我们不需要克隆.只需告诉 git 获取增量.最终结果:即时克隆.令人印象深刻.

一致性怎么样?
从工作目录执行简单的git pull"将使用 delta 的摘要实现已推送到共享存储库的更改.
没事做.再次令人印象深刻.

当然，当构建在第二个目录中运行时，我们可以继续处理代码.无需等待.

我们现在拥有一个无需维护、无需额外安装、不依赖于 IDE、使用单个命令行运行的私有构建.共享存储库中不再有损坏的构建.我们可以回收我们的 CI 服务器.

是的.你听得很好.我们刚刚构建了一个无服务器 CI.真正的 CI 服务器的每一个附加功能对我来说都是噪音.

#!/bin/bashif [ 0 -eq `git remote -v |grep -c push`];然后REMOTE_REPO=`git remote -v |sed 's/起源//'`别的REMOTE_REPO=`git remote -v |grep "(推)" |sed 's/起源//' |sed 's/(push)//'`菲如果 [ ！-z "$1" ];然后git 添加.git commit -a -m "$1"菲拉如果 [ ！-d ".privatebuild" ];然后混帐克隆..privatebuild菲光盘 .privatebuildgit clean -df拉如果 [ -e "pom.xml" ];然后mvn 全新安装如果 [$?-eq 0 ];然后echo "发布到:$REMOTE_REPO"git push $REMOTE_REPO 主别的echo "无法构建"退出 $?菲菲

<小时>

Dmitry Tashkinov，他有一个 关于 DVCS 和 CI 的有趣问题，问:

<块引用>

我不明白我们刚刚构建了一个无服务器 CI"如何与 Martin Fowler 的状态一致:
一旦我自己构建了一个正确同步的工作副本，我就可以最终将我的更改提交到主线，然后更新存储库.但是我的提交并没有完成我的工作.此时我们再次构建，但是这个在基于主线代码的集成机器上的时间.只有当这个构建成功时，我们才能说我的更改已经完成.总是有可能我错过了我的机器上的某些东西并且存储库没有正确更新."
你是忽略还是弯曲它?

<块引用>

@Dmitry:我不会忽略也不会改变 Martin Fowler 在他的 ContinuousIntegration 条目中描述的过程.
但您必须意识到DVCS 将发布添加为分支的正交维度.
David 描述的无服务器 CI 只是 Martin 详述的一般 CI 流程的一个实现:您无需使用 CI 服务器，而是推送到运行本地 CI 的本地副本，然后将有效"代码推送到中央存储库.

<块引用>

@VonC，但这个想法是在本地运行 CI，特别是不要错过机器之间的转换.
当您使用所谓的本地 CI 时，它可能会因为它是本地的而通过所有测试，但稍后会在另一台机器上崩溃.
那么它是整数吗?我完全不是在这里批评，这个问题对我来说很难，我正在努力理解.

<块引用>

@Dmitry:那是整数化吗?"
它是一种集成级别，可以帮助摆脱所有基本检查(如格式问题、代码样式、基本静态分析检测等)
由于您拥有该发布机制，因此您可以根据需要将这种 CI 链接到另一个 CI 服务器.反过来，该服务器可以自动推送(如果这仍然是快进)到中央"存储库.

David Gageot 不需要那个额外的级别，在部署架构 (PC->PC) 方面已经达到目标，并且只需要那种基本的 CI 级别.
这并不妨碍他设置更完整的系统集成服务器以进行更完整的测试.

This actually stems from on my earlier question where one of the answers made me wonder how people are using the scm/repository in different ways for development.

解决方案

Pre-tested commits

Before (TeamCity, build manager):

The concept is simple, the build system stands as a roadblock between your commit entering trunk and only after the build system determines that your commit doesn't break things does it allow the commit to be introduced into version control, where other developers will sync and integrate that change into their local working copies

After (using a DVCS like Git, that is a source repository):

My workflow with Hudson for pre-tested commits involves three separate Git repositories:

• my local repo (local),
• the canonical/central repo (origin)
• and my "world-readable" (inside the firewall) repo (public).

For pre-tested commits, I utilize a constantly changing branch called "pu" (potential updates) on the world-readable repo.
Inside of Hudson I created a job that polls the world-readable repo (public) for changes in the "pu" branch and will kick off builds when updates are pushed.

my workflow for taking a change from inception to origin is:

* hack, hack, hack
* commit to local/topic
* git pup public
* Hudson polls public/pu
* Hudson runs potential-updates job
* Tests fail?
      o Yes: Rework commit, try again
      o No: Continue
* Rebase onto local/master
* Push to origin/master

Using this pre-tested commit workflow I can offload the majority of my testing requirements to the build system's cluster of machines instead of running them locally, meaning I can spend the majority of my time writing code instead of waiting for tests to complete on my own machine in between coding iterations.

---

(Variation) Private Build (David Gageot, Algodeal)

Same principle than above, but the build is done on the same workstation than the one used to develop, but on a cloned repo:

How not to use a CI server in the long term and not suffer the increasing time lost staring at the builds locally?

With git, it’s a piece of cake.
First, we ‘git clone’ the working directory to another folder. Git does the copy very quickly.
Next times, we don’t need to clone. Just tell git get the deltas. Net result: instant cloning. Impressive.

What about the consistency?
Doing a simple ‘git pull’ from the working directory will realize, using delta’s digests, that the changes where already pushed on the shared repository.
Nothing to do. Impressive again.

Of course, while the build is running in the second directory, we can keep on working on the code. No need to wait.

We now have a private build with no maintenance, no additional installation, not dependant on the IDE, ran with a single command line. No more broken build in the shared repository. We can recycle our CI server.

Yes. You’ve heard well. We’ve just built a serverless CI. Every additional feature of a real CI server is noise to me.

#!/bin/bash
if [ 0 -eq `git remote -v | grep -c push` ]; then
  REMOTE_REPO=`git remote -v | sed 's/origin//'`
else
  REMOTE_REPO=`git remote -v | grep "(push)" | sed 's/origin//' | sed 's/(push)//'`
fi

if [ ! -z "$1" ]; then
  git add .
  git commit -a -m "$1"
fi

git pull

if [ ! -d ".privatebuild" ]; then
  git clone . .privatebuild
fi

cd .privatebuild
git clean -df
git pull

if [ -e "pom.xml" ]; then
  mvn clean install

  if [ $? -eq 0 ]; then
    echo "Publishing to: $REMOTE_REPO"
    git push $REMOTE_REPO master
  else
    echo "Unable to build"
    exit $?
  fi
fi

---

Dmitry Tashkinov, who has an interesting question on DVCS and CI, asks:

I don't understand how "We’ve just built a serverless CI" cohere with Martin Fowler's state:
"Once I have made my own build of a properly synchronized working copy I can then finally commit my changes into the mainline, which then updates the repository. However my commit doesn't finish my work. At this point we build again, but this time on an integration machine based on the mainline code. Only when this build succeeds can we say that my changes are done. There is always a chance that I missed something on my machine and the repository wasn't properly updated."
Do you ignore or bend it?

@Dmitry: I do not ignore nor bend the process described by Martin Fowler in his ContinuousIntegration entry.
But you have to realize that DVCS adds publication as an orthogonal dimension to branching.
The serverless CI described by David is just an implementation of the general CI process detailed by Martin: instead of having a CI server, you push to a local copy where a local CI runs, then you push "valid" code to a central repo.

@VonC, but the idea was to run CI NOT locally particularly not to miss something in transition between machines.
When you use the so called local CI, then it may pass all the tests just because it is local, but break down later on another machine.
So is it integeration? I'm not criticizing here at all, the question is difficult to me and I'm trying to understand.

@Dmitry: "So is it integeration"?
It is one level of integration, which can help get rid of all the basic checks (like format issue, code style, basic static analysis detection, ...)
Since you have that publication mechanism, you can chain that kind of CI to another CI server if you want. That server, in turn, can automatically push (if this is still fast-forward) to the "central" repo.

David Gageot didn't need that extra level, being already at target in term of deployment architecture (PC->PC) and needed only that basic kind of CI level.
That doesn't prevent him to setup more complete system integration server for more complete testing.

这篇关于您见过的最聪明的源代码库使用方法是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！