发布网友 发布时间:2022-04-19 20:52
共2个回答
热心网友 时间:2023-10-15 12:09
首先先做基层,比如开发,比如运维然后开始做team leader然后开始做project leader然后在发展的话,看你自己的方向,如果还是技术,那就架构师,如果不是,那就是管理职位热心网友 时间:2023-10-15 12:09
环境快速管理
移动迅速的团队无法在原地等待获得构建和测试的环境,也等不了已经超载的DBA,用人工方式来输入数据或者模式变更。
自服务团队
快速移动的团队需要自服务。组织需要移动系统管理和访问权限从集中管理转移到各个团队。
可脚本数据库
脚本数据库的变化意味着在源代码控制权限中,存储模式和数据在系统代码版本的适当旁边。许多工具集都为主要数据库提供了这个脚本,不管它们是传统的RDBMSs还是“NoSQL”。
可脚本数据
设计良好的应用包含API,公开了主要功能:创建一个用户、帐户或产品。
功能管理
组织常常忽视业务实现的影响:选择什么功能,它们是如何被构思的,以及是如何被编码的。
较小的功能
较小的功能通常不太复杂,因此作为CI / CD管道的一部分更容易构建。通过一小组API、数据库变更和UI,它更容易构建、集成、测试和部署一个较小的组件,而不是大量的模式更新、相互交织的服务依赖项,以及为最终用户安装许多组件。
可切换的功能
大规模功能就可以切换打开或关闭,这让系统变得更容易测试。
进程
移动到一个不断交付高质量、测试良好的软件的管道中,这通常是流程变更,而不是技术变更。
迁移到小分支
分支策略常常与tabs versus spaces或Emacs versus Vim一样备受争议。团队选择的分支策略将对团队在CI / CD环境中尽可能顺利地工作能力产生重大影响。
在源代码中测试
保持自动化测试与他们所覆盖的系统同步,这对自动化交付管道至关重要。处理这一问题的最平稳的方法就是将自动化的测试代码保存在与系统代码相同的存储库中。
代码
考虑一个代码库的技术影响,以确保快速交付管道的良好的可测试性
利用API可测试性
公共API是任何结构良好的系统的重要组成部分,不管它是一个单层系统还是由许多基于服务的组件组成的系统。
管理代码依赖项
向外部服务注入依赖项,是团队在不依赖外部系统的情况下,能够在较低环境中支持系统的一种方法。举例来说,想象一个有调用外部安全系统的工资系统。