Subversion (SVN)

问题： I've been using Git now for a couple of months on a project with one other developer. 我和其他开发人员一起在一个项目上使用Git几个月了。 I have several years of experience with SVN , so I guess I bring a lot of baggage to the relationship. 我有几年的 SVN 经验，所以我想我给这段关系带来了很多包袱。 I have heard that Git is excellent for branching and merging, and so far, I just don't see it. 我听说Git非常适合分支和合并，到目前为止，我只是没有看到它。 Sure, branching is dead simple, but when I try to merge, everything goes all to hell. 当然，分支很简单，但是当我尝试合并时，一切都变得很糟糕。 Now, I'm used to that from SVN, but it seems to me that I just traded one sub-par versioning system for

API（应用程序接口）正逐渐成为很多软件开发的中心，不同的系统、应用通过API连接、传输数据、互相交互。越多越多的系统从MVC架构转向微服务架构，各个微服务之间通过Rest API进行交互。对于企业来说，相比产品开发完成后，进行UI测试，API测试更容易发现问题，更可能在早期阶段发现问题。并且API测试成本更低，更容易实现自动化测试，并且有更多的成熟的自动化测试工具可以使用，比如RestBird、Postman、SmartBear等，大大提高效率 。 1.什么是API接口测试？API测试和UI测试有什么区别？ API应用一般分为三层：数据层、服务（API）层、展现（UI）层。API层，即业务逻辑层，一般包括用户业务逻辑、用户和服务、数据、应用功能交互规则。API直接触及数据层和展现层，API测试是开发测试团队可持续、自动化测试最佳切入点。有助于大幅提高软件交付质量、系统稳定性。目前，传统测试更聚焦UI层测试，但接口测试的优势和价值目前已经被普遍认可。 API测试：通常向一个和多个API发送请求，并验证响应，以检查性能、安全、功能正确性、返回状态等。 UI测试：通常聚焦验证Web/APP的界面展示、按钮/控件的操作、通过控件操作验证功能等。 与UI测试相比，API测试更多聚焦业务逻辑、数据响应、安全、性能瓶颈等。 加入我们，测试交流群，642830685

以前这个gradle都是给Android使用的，万万没想到，Java的其它项目也能使用，甚至能替代maven或者说maven和gradle项目是可以互相转换的。还有就是在使用svn来管理项目的时候，每个svn版本都对应一个数字，但是换了git之后，每个提交记录就不是简单的生成个int数字，还是递增的数字了，对应的是个hash值，类似Java对象的hashcode，这个时候就希望，每次项目打包之后，产生出来的jar包带上这个git版本号，虽然不似svn那样一个简单的int数字就能说明版本，但是git的hash值还是可以凑合用的，也能对应找到提交版本记录。 首先在最外层的根 build.gradle文件里面定义几个全局的方法，子模块项目就可以直接使用，而不用再复制一次。 static def gitHashAndBuildTime() { return "-" + getGitSHA() + "-" + releaseTime() } static def releaseTime() { return new Date().format("yyyy-MM-dd HH:mm", TimeZone.getTimeZone("GMT+08:00")) } static def getGitSHA() { return 'git rev-parse --short HEAD'.execute(

​转载本文需注明出处：微信公众号EAWorld，违者必究。 // DevOps（开发：Development和运维：Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。 ——by 百度百科 // 今天的主题就是有关DevOps的很重要的一部分，Development中代码模块的设计。 代码模块说复杂也不复杂说简单也不简单，复杂是说它上承接着任务模块，下关联着构建模块，功能涉及到代码的对比合并、质量分析、关联的任务项等，缺了它就凑不成完整的DevOps流程。 简单是说该模块需要关注的点无非就是质量以及效率，一个项目在我看来代码才是根本，代码的产出质量效率越高，就越是节省项目的成本，有钱赚才是硬道理。 代码模块的受众也无非两类人： 开发人员 和 上层领导 。 开发人员眼中的代码模块是branch、tag、code、merge-request、quality等等诸多功能模块的混合体。 不行了，晕了 但是到了领导的眼里，报表即可解决问题： 一类报表说了张三今天代码产出了多少的缺陷多少的漏洞。 垃圾代码冠军得主，就是你 另一类报表说了李四本周就敲了10行代码效率极其低下。 是时候该炒李四鱿鱼了 所以创造一个 友好的代码管理功能交互页面 以及 简洁明了的代码质量效率报表界面

【以下为分享实录，有删节】 阿里巴巴为什么要自研代码管理平台 也许你会问：为什么阿里巴巴要重新做一套代码管理平台，继续用GitLab版本不是挺好的吗？接下来从我个人的角度在这里尝试进行解答。 由于历史原因，在阿里巴巴集团内部代码平台是整个DevOps领域中起步相对较晚的一块业务域，相比于发布域、测试域有着多年的积累和沉淀来讲，2017年时的代码平台可以说是为了满足整体业务需求由几个系统强行拼凑起来的。 为了支撑起阿里巴巴整体的业务发展，研发团队要同时维护6个系统，分别是负责代码托管的GitLab、Svn、Gerrit，以及负责上层代码服务的Phabricator、CodeCenter、ScmCenter。且其中除了CodeCenter、ScmCenter之外，其它四个均是在开源系统之上二次封装改造而来的。其中Gitlab技术栈是基于Ruby，Phabricator基于PHP，SVN基于C，Gerrit基于Java,这给我们日常的开发和维护工作增加了很多负担。 当时代码平台遇到的困难和挑战主要有四个方面： 一、技术架构方面：多套系统架构，多种开发语言，不仅维护成本高，且与阿里集团的主流技术脱节，研发团队同学每天疲于填坑，然而整体上却得不到大的改善。 二、平台发展方面：单纯的Gitlab、Svn、Gerrit均无法与周边关联系统做到有效协同

ubuntu搭建svn、git遇到的问题及解决办法 参考文章： （1）ubuntu搭建svn、git遇到的问题及解决办法 （2）https://www.cnblogs.com/sky-heaven/p/5186591.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/u/4265074/blog/4297658

问题： I get this error when I do an svn update : 我在进行 svn update 时遇到此错误： Working copy XXXXXXXX locked Please execute "Cleanup" command 工作副本XXXXXXXX已锁定请执行“清理”命令 When I run cleanup, I get 当我进行清理时，我得到了 Cleanup failed to process the following paths: XXXXXXXX 清理无法处理以下路径：XXXXXXXX How do I get out of this loop? 我怎么摆脱这个循环？ 解决方案： 参考一： https://stackoom.com/question/XHQ/SVN中的工作副本XXX已锁定并且清除失败 参考二： https://oldbug.net/q/XHQ/Working-copy-XXX-locked-and-cleanup-failed-in-SVN 来源： oschina 链接： https://my.oschina.net/u/3797416/blog/4278873

gitlab 1. 版本控制介绍 版本控制是指对软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理，是软件配置管理的核心思想之一。 版本控制最主要的功能就是追踪文件的变更。它将什么时候、什么人更改了文件的什么内容等信息忠实地了记录下来。每一次文件的改变，文件的版本号都将增加。除了记录版本变更外，版本控制的另一个重要功能是并行开发。软件开发往往是多人协同作业，版本控制可以有效地解决版本的同步以及不同开发者之间的开发通信问题，提高协同开发的效率。并行开发中最常见的不同版本软件的错误(Bug)修正问题也可以通过版本控制中分支与合并的方法有效地解决。 具体来说，在每一项开发任务中，都需要首先设定开发基线，确定各个配置项的开发初始版本，在开发过程中，开发人员基于开发基线的版本，开发出所需的目标版本。当发生需求变更时，通过对变更的评估，确定变更的影响范围，对被影响的配置项的版本进行修改，根据变更的性质使配置项的版本树继续延伸或产生新的分支，形成新的目标版本，而对于不受变更影响的配置项则不应发产生变动。同时，应能够将变更所产生的对版本的影响进行记录和跟踪。必要时还可以回退到以前的版本。例如当开发需求或需求变更被取消时，就需要有能力将版本回退到开发基线版本。在曾经出现过的季度升级包拆包和重新组包的过程中，其实就是将部分配置项的版本回退到开发基线，将对应不同需求的不同分支重新组合归并

git 是一个分布式的版本控制器，与SVN不一样，SVN只有一个中央的版本控制器。 工作目录，暂存区，版本库 工作目录（工作区）：就是你敲代码的文件目录 暂存区：.git文件夹中的index文件就是暂存区，也可以叫做stage，暂存区是一个临时保存文件修改的地方 版本库：就是隐藏的.git文件夹，存储了很多隐藏的配置信息，日志信息，版本信息 工作目录 --》git add --》暂存区--》git commit --》版本库 文件状态： unTracked 未跟踪状态 （未纳入版本控制） tracked 已跟踪状态（被纳入版本控制） unModified 未修改状态 Modified 已修改状态 Staged 暂存状态 git忽略文件（touch .gitignore） ： 在工作目录下创建一个.gitignore的文件，利用正则匹配文件名或者文件目录名 *.a: 所有，a的后缀都要忽略 !lib.a 不忽略lib.a doc/**/*.pdf doc目录下的所有.pdf的文件 拉取与抓取： fetch（抓取）：不会自动合并 抓取远程仓库的文件到 .git的object文件夹下 pull（拉取）：自动合并 抓取远程仓库的文件到 .git的object文件夹下，并且与你的本地仓库进行合并。 分支 ： 默认clone下来是在master分支下，本地和远程仓库都存在分支情况。 git

Jenkins是什么 Jenkins是一个开源的、提供友好操作界面的持续集成(CI)工具，起源于Hudson（Hudson是商用的），主要用于持续、自动的构建/测试软件项目、监控外部任务的运行（这个比较抽象，暂且写上，不做解释）。Jenkins用Java语言编写，可在Tomcat等流行的servlet容器中运行，也可独立运行。通常与版本管理工具(SCM)、构建工具结合使用。常用的版本控制工具有SVN、GIT，构建工具有Maven、Ant、Gradle。 使用Jenkins对Java代码进行打包 Jenkins是一个强大的CI工具，虽然本身使用Java开发，但也能用来做其他语言开发的项目CI。下面讲解如何使用Jenkins创建一个构建任务。 1. 登录Jenkins，点击新建任务 之后进入到这个界面，任务名称可以自行设定，但需要全局唯一。输入名称后选择构建一个自由风格的软件项目(有时选择第二个：构建一个maven项目)，并点击下方的确定按钮即创建了一个构建任务，然后就会自动跳转到该job的配置页面。 2. 配置界面，配置项详解 2.1 General ：是构建任务的一些基本配置。名称，描述之类的。 2.2 源码管理 ：源码管理就是配置你代码的存放位置。 2.3 构建触发器 ：顾名思义，就是构建任务的触发器。 2.4 构建环境 ：就是构建之前的一些准备工作，如指定构建工具。