源代码管理及软件配置 | 学习笔记

简介: 快速学习源代码管理及软件配置

开发者学堂课程【ALPD 云架构师系列:云原生 DevOps 36计-阿里云云效出品源代码管理及软件配置】学习笔记,与课程紧密连接,让用户快速学习知识。

课程地址https://developer.aliyun.com/learning/course/772/detail/13499


源代码管理及软件配置


内容介绍:

一. 在软件交互的过程中,以代码为中心软件的作用

二. 如何管理代码或软件配置?

三. 问题:假设所有的代码都保存在一个代码库,且所有人均可访问,代码库应该怎么组织?

四. 问题:软件配置经常被修改,被发布,它属于代码吗?

五. 问题:alpd-demo 应用里面有没有启动配置和运行配置的例子?

六. Takeaways


一. 在软件交互的过程中,以代码为中心软件的作用

1.保存最终的交互制品。通过代码来描述,要交互成一个什么样子。代码定义了系统应该怎么工作,代码定义了我们的软件是怎么交付的,代码定义了我们的环境应该是怎么样,所有东西都是围绕代码。

2.代码是整个团队协作的一个工具。


二. 如何管理代码或软件配置?

image.png

上图是某个公司的一个代码的组织结构,把目录当做一个代码组, qinglong 是下面的子代码组,aTeam 又是一个子代码组。

这个代码组织结构,都有什么问题?

1. 目录中同时有中文和英文,代码组的命名方式混乱。

2. 用代码库存储外部二进制文件。整个代码库的性能消耗非常大,方式不合理。

3. 同一归属的代码库保存在不同的代码组中。

4. 公共库保存在子代码组里。

5. 应用的文档(或测试)与应用分开存放。


三. 问题:假设所有的代码都保存在一个代码库,且所有人均可访问,代码库应该怎么组织?

答案:代码组(+子代码组)+Git 代码库=大库

认识代码的组织方式的时候,代码是可以分组的。

比如这个代码组对应的代码就用一个代码库。假设所有的代码都保存在一个代码库,且所有人均可访问,代码库应该怎么组织?代码组,子代码组还有代码库,这些这么多的资源如何在一起?

本质上,它要组合成一个大库的一个形式,用很多不同的小库加上代码组来形成这个逻辑上的这个概念。

看上图例子,它合理的一个代码组织结构应该是什么样?

首先,这个系统里面有两个应用,一个是risk 一个是data, 然后每个应用下面有很多的服务,或者文档,然后有一个空公共的一个 model 叫 common-lib ,这个是被所有的应用所依赖的。

然后,把从属于同一个应用的这些给他库的放到一起。另外,让这个 common 那个放到他该有的地方去。这样就分得清,分得近了。然后不像刚才一样,按照团队来去划分 ,而是按照应用组划分,那这样就会比较清楚。

1. 实践建议

⑴代码库的内容:

①软件的源代码(Production Code)

软件的源代码就是生产模式的,另外像名单、测试这些东西,也应该放在那些地方,因为它们都是一伙的。

②将文档(和测试)的 git 库放到其相关应用组下

③不要将一些制品(如系统二进制包)保存在代码库中

很多公司里很常见的一个问题就是,把一些制品(如系统二进制包)保存在代码库中,这其实是有点问题的,因为本身是二进制文件领头的时候,代码库里的容量很大,一般流量大、小文件多,同时这个文件是怎么来的无法追溯。

⑵代码库的组织结构:

①按照系统、应用和模块的层次来组织代码库(分清层次)

②同一个系统/应用层级的所有内容位于同一个代码组下(归纳整理)

⑶代码库的可见性:

①通用代码库放在其通用级别都可以访问的位置

哪些是是一些人看的,哪些是给所有人看的,哪些应该是放给某一个应用里的所有人看的,这些东西要考虑清楚。

通用代码库放在其通用级别都可以访问的位置,因为所有用户都依赖它,如果它是一个工作的东西,就应该在公共的位置,同时可以看到,并且能够去改。这就相当于公共的地方意味着所有人都对它有诉求,所以放在公共位置也更容易大家去修改它。

②除核心算法等少数代码库外,尽量代码库的访问在同一系统/应用对有相关人员公开

这样让大家能看到全貌,否则我不知道它存在哪里,这样的话我会产生一些陷阱,比如我可能不知道去哪改,或者随便建个模,就会带来一些风险。而且可能未来对整个软件的价格来说也没有好处。但如果很难做到这一点,也建议在代码库里给一个结构,让整个参与这个项目的人都知道一个大概的整体是怎么样。

这就是一个代码的简单的组织方式。在整个过程当中,所有的开发者都是围绕着代码库,然后做相应的一些协作活动。

2. 软件交付过程,其本质是开发者围绕代码库的协作过程

image.png

这里铺设的操作都是围绕在 commit 上去展开的,分三点相应的借鉴。

⑴ SMALL

①一个应用一个 Git 仓库

②不在 Git 上存储构建产物和其他二进制文件

small什么意思,就是说这个库应该要尽可能的小。这里不太建议很大,尤其在目前基础设施的这种状况下。就应该一个应用就是一个 Git 仓库。而不是一个仓库里包含多个应用,这个情况下,当你维护起来就很不方便。

虽然把构建存在我的仓库给别人很方便,但是这其实不太好,这样很难追溯这个构建产物是现在的代码产生出来的,还是之前产生出来的。

⑵ LINEAR

①多用 rebase,少用 merge

②避免无效 commit

不要那种无意义的merge,就这个merge应该是明确的,那么尽量的用rebase操作。

避免无效 commit,就有一个空间很长,后面有好多,但是里面大部分是无效的,都是一些没有用的。可能只是写了一行代码还没写完,这个就不完整。

⑶ ATOMIC

①一个 commit 解决一个问题

②问题尽可能小

原子性意思是一个原子操作。原子性有什么好处呢,原子性是解决一个特定的问题。比如修复一个pas,或者加了一个功能,或加了一个API,这就是一个非常明确的问题。然后就一个 commit 解决一个问题,这样追溯就很容易追溯,就知道这个是做了什么,下个是做了什么。

第二个问题,问题不能很大。不能写了两千行代码解决了一个问题提交,这非常危险。因为这中间没有实验,没节奏。对开发者来讲,比较好的情况就是很快速的有一个阶段性的成果,并且能持续有反馈,持续的往返目标去贴近它。但如果前面憋了很久,一直也不知道怎么样最后一把搞定,这对开发体验是不太好的,而且协作上来讲也不好。因为别人不知道你做多少了,所以问题要尽可能的尽可能的小。

3. Commit 的常见的反模式

⑴无效的 commit,如 Merge branch'develop'of https://codeup.aliyun.com/abc/xyz into develop

几乎在所有的公司,可能随便拉开一个代码过去,发现怎么有这么多本地和远程的这种情况。本来一个被搞定的里面没有用正确方式,这个就导致很多无效的,这样就会对commit的追溯能力产生很大的影响。

⑵巨型 commit,一个 commit 里面包含了大量的代码变化,且属于多个实现目的

比如做了三千行代码,就完全找不着它想干什么,这就非常危险。

⑶半成品的 commit,如包含有基本语法问题或实现错误的代码的 commit

比如我要去吃饭了,就先提交了,可能这个代码连编译都过不了,但这个其实是不好的。

⑷分支间的互相 merge

如果分支间的互相合并多了,就会发现commit的追溯就很难了,而且很有可能出问题。应该有唯一的主干,或者说一个明确的主干,这样往那边去合或从那边来,而不应该是互相的merge。


四. 问题:软件配置经常被修改,被发布,它属于代码吗?

答案:配置是另一种形式的代码

在实际工作中,配置有可能不存在仓库里,可能在配置中心或者一个系统里,但是配置就是一种代码。

1. 启动相关的配置

(DB 连接串,容器 CPU 规格,启动模式,DNS 服务地址)

⑴构建到镜像中或作为启动参数传入。

⑵启动之后不再更改,无需动态监听其变化。

⑶对这类配置的修改,会生成新的容器或 Pod。

⑷需要对运行中的服务进行重启,才能使这类配置的修改生效。

2. 运行相关的配置

(日志级别,黑白名单,特性开关,监控采样频率)

⑴通常通过监听某个服务或文件来获取和更新。

比如,读一个白名单,他的配置的更新不需要修改容器和pod,但是更新完全跟容器和pod没关系,就更新了。

⑵配置的更新无需修改容器和 Pod。

⑶运行中的容器通过持续监听配置的变化,有变化后自动生效无需重启。


五. 问题:alpd-demo 应用里面有没有启动配置和运行配置的例子?

image.png

如上图例子,这个是 ssh 服务的一个配置,这里 k8s 这些在文件上,这个就是在启动的时候,设的一个参数。另一个,我们在那个 query 服务里面,有一个WEATHER-API-KEY, 通过 secret  的方式注入到alpd里面,用环境变量去进入渠道。所以在其实运行的时候,是一样的配置,可以不去关心这个容器的重启,就当他生效。

从另外一个角度来去看一下配置的不同层次。

image.png 

位于越内存的配置,修改成本是越高。

为什么这个箭头是从上往下的?如果是编码级别的,改的话 我要经过所有下面的阶段才能够上线,如果是运营阶段的话, 其实是不需要动前面的部分的,所以如果是这个配置位于越内层,那它的成本显然是越高的。


六. Takeaways 回顾要点

1. 不可变构建:相同的源码+相同的环境+相同的构建脚本=>一致的软件制品

2. 通过 Docker file 描述构建环境、构建脚本及运行环境

3. 构建的准确性>构建的效率

4. One process per container,避免采用富容器,降低镜像的大小

5. 按逻辑单库的结构组织代码库和代码组

6. 软件交付过程,其本质是开发者围绕代码库的协作过程,按照 SLA(Small、Linear、Atomic)的原则提交代码

7. 根据使用方式区分启动配置和运行配置,将环境相关的配置与镜像分离

8. 尽量将配置定义在外层,以减少修改的成本

整个逻辑是要交付一个东西要标准,要不可变。标准通过容器镜像的方式去标准化;不可变因为终态要保证稳定可预期的系统服务,所以交付的质品希望是不可变的,在构建的依赖,构建环境,构建脚本这些是要确定性的。从代码构建的源头是从代码开始,代码的组织是按什么样的方式组织;代码提交是按什么样的原则,从配置角度,有启动配置,运行时的配置,怎样最小化的修改运行成本,尽可能让配置放在最外层。

相关文章
|
15天前
|
Java Serverless Maven
云效代码管理问题之代码仓库配置需要评审如何解决
云效仓库是阿里云提供的代码托管和版本控制服务,支持Git等多种版本管理工具;本合集聚焦于云效仓库的使用技巧、团队协作流程以及常见问题解答,旨在帮助开发者更高效地进行代码管理和协作开发。
1768 0
|
存储 算法 Cloud Native
源代码管理及软件配置(一)|学习笔记
快速学习源代码管理及软件配置(一)
149 0
源代码管理及软件配置(一)|学习笔记
|
监控 Cloud Native 架构师
源代码管理及软件配置(二)|学习笔记
快速学习源代码管理及软件配置(二)
139 0
源代码管理及软件配置(二)|学习笔记
|
15天前
|
Shell 开发工具 git
云效代码管理可以通过以下步骤统一更换地址链接
【1月更文挑战第21天】【1月更文挑战第102篇】云效代码管理可以通过以下步骤统一更换地址链接
128 1
|
8月前
|
运维 安全 数据可视化
免费托管代码到云效代码管理Codeup
本场景介绍如何提交代码到云效代码管理Codeup。云效Codeup提供免费、不限容量的云上代码托管服务,您无需担心计费问题。
767 0
|
15天前
|
敏捷开发 Serverless 测试技术
云效产品使用常见问题之代码管理单文件超过200m无法上传如何解决
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。
|
15天前
|
Shell 开发工具 git
云效代码管理可以通过以下步骤统一更换地址链接
云效代码管理可以通过以下步骤统一更换地址链接
46 3
|
架构师 开发工具 开发者
《开发者评测》之云效代码管理Codeup评测活动获奖名单
云效代码管理Codeup评测活动获奖名单出炉啦!
|
安全 前端开发 Java
阿里云产品测评 云效代码管理 Codeup
阿里云产品测评 云效代码管理 Codeup
329 1