Recommended
More Related Content
Viewers also liked
Viewers also liked (17)
Similar to 持续交付 - 使用云计算和虚拟化技术
Similar to 持续交付 - 使用云计算和虚拟化技术 (20)
More from foxgem
Recently uploaded
Recently uploaded (20)
持续交付 - 使用云计算和虚拟化技术
- 2. 个人简介 冯智超 chaojiwudi.com 程序员; 准Geek; 伪军迷;
- 3. 向客户交付价值
- 4. 手工部署
- 5. 自动化
- 6. 一切皆代码
- 7. 流水线
- 8. 流水线监控
- 9. 尽可能模拟产品环境
- 10. 云和虚拟化
- 11. Chef
- 13. • chef server/client • chef solo • role • cookbook • recipe • resource/provider
- 14. Amazon VPC
- 15. • ec2-run-instances ami-a54d67d1 -- instance-type t1.micro --region us- west-1 --key MY_AMZ_KEY • knife ec2 server create "role[rails_server]" --image ami- 31814f58 --flavor t1.micro -- availability-zone us-east-1a --ssh-key MY_AMZ_KEY
- 16. vagrant
- 17. Vagrant::Config.run do |config| config.vm.box = "centos6" config.vm.provision :chef_solo do |chef| chef.cookbooks_path = "/PATH/TO/chef- repo/cookbooks" chef.roles_path = "/PATH/TO/chef-repo/roles" chef.add_role "db_master_server" end end
- 18. • yun node create NODE_NAME • yun node list • yun node destroy NODE_NAME • yunssh NODE_NAME • yun chef NODE_NAME ROLE +---------------------+------------+--------------+--------------+-------+---------+----------+ | created_at | id | image | ip | name | state | type | +---------------------+------------+--------------+--------------+-------+---------+----------+ | 2011-12-09 19:06:45 | i-b3442af4 | ami-2e10406b | | test2 | stopped | t1.micro | | 2011-12-09 20:03:34 | i-e95a34ae | ami-2e10406b | | test3 | stopped | t1.micro | | 2011-12-09 21:05:15 | i-3f513f78 | ami-2e10406b | 50.18.4.229 | ci | running | m1.small | | 2011-12-10 01:15:36 | i-8782ecc0 | ami-2e10406b | 50.18.36.117 | qa | running | t1.micro | +---------------------+------------+--------------+--------------+-------+---------+----------+ 4 rows in set
- 19. button-click 部署
- 20. local machine CI server Acceptance Git Acceptance Acceptance Package Package Publish Standalone Repo Standalone Staging the same as local CI EC2/VMW Repo are Dist Repo Prod A Prod B QA / Performance / BAT … Pre-Production Production EC2/VMW EC2/VMW EC2/VMW are are are
- 21. OS: centos node server: apache app: tomcat + war config files web db environment back search end QA test uat staging perfomance showcase test
- 22. 个人经验
Editor's Notes
- 提问：多少人是dev？多少人是ops？没举手的就是PM上学时候，微软技术创新日，两个会场，Dev&ITPro实际案例，个人理解、体会。抛砖引玉，引起讨论。项目简介
- 有个腾讯陈小光讲师开过4年装甲车，所以我是伪军迷，伪_军迷，不是 伪军_迷程序员、准Geek、伪军迷
- 表明客户希望看到的是最终可用的软件能带来价值1，程序员仅仅是写产品代码吗？代码只是开发的一部分，还有需求、测试、部署。测试代码？需求代码？部署代码？2，仅仅是程序员写代码吗？团队中有PM、dev、QA、UI。以及Ops？一个典型的小团队，1PM，1BA，4-5Dev，1-2QA，UX、producer3，开发完成后才部署？反模式持续交付不是仅仅注重在“交付”，不是持续部署，而是能保证任何时刻都有可以产生价值的软件。某团队工作半年，领导视察，费半天的劲儿搞出一个版本，一点，500error我们都知道懒惰、缺乏耐性、傲慢。
- 慢、无版本控制、不可重复、容易出错、无法知识分享无法持续重复做的事情，即无法保证其是正确的（所以有自动化测试、持续集成等）部署的时间过长、过复杂，导致开发人员不愿意做部署，且反馈太慢（如果一个过程经常出错，很容易掩盖真正的错误。）真实案例：build经常红，随机失败或者配置问题，导致大家降低代码提交的要求，并掩盖了代码真实的bug，带入到了 pre-production 环境无版本控制、无可执行的代码，导致知识很难在团队间分享（代码才是程序员的共同语言）遇到问题时，开发人员很容易绕过（work around），导致经验不能累积传递、问题反复出现（特别是对于有些“经验”的程序员，实际案例：imageserver）
- 部署过程代码化、部署代码是项目（软件）的一部分，one button click 到任意环境测试包含了对软件的测试，以及对部署的测试，使用 虚拟机、云平台 更方便的实现自动化部署代码可执行、放在代码库中可版本控制、可重复、自动化运行检测了软件能否交付价值（在愈来愈真实的环境中）既然是代码，那么如何对其测试，部署就是测试如果一件事情很复杂困难，那么一定要频繁的做需要有自动化的基础设施管理能力，比如很方便的创建一个节点甚至一整套环境；部署过程代码化，能够自动化的安装、配置软件；在向各个环境部署时，使用相同的自动化代码；各个环境与生产环境都需要尽可能的相似，有同样的操作系统底层组件网络配置等。
- 所有东西（代码、测试、需求、配置、脚步）都在版本控制中（二进制结果不需要），主干开发、feature toggle保证可以从 git clone codebase 能build出产品buildr开始，还是从bash开始？rvm、ruby、gem、bundle、javaruby代码比java多，4个页面，150个左右的场景测试50+的cookbook
- 持续集成：关注开发测试，持续交付：关注全过程（包括部署）所有的开发、测试、部署构成了一条流水线，分别跑在云EC2上和虚拟机上。每个步骤都包含了对产品的 部署和测试。每次提交都会触发一次流水线、反馈关注部署不代表持续部署到生产环境，但是需要有持续部署到生产环境的能力。stage：1， package 编译打包、单元测试、静态检查、rpm&deb包； 2，standalone 环境测试 隔离外部组件、自动化验收测试3，EC2 环境测试 在虚拟、云上创建所有组件，自动化集成测试； 4，publish 发布package 和脚本、配置到团队的 package source快速反馈、增强信心
- 不代表需要持续部署到生产环境，但需要有持续保证部署到生产环境的能力，才能保证能持续产生价值如何保证有能力部署到生产环境？创建一个类似生产环境的环境，持续向其部署并持续测试需要很快的反馈（分布式）收到反馈团队需要有行动增强团队信息、减少错误、降低压力每次流水线都带来一个可release的版本快速反馈，快速修复，timebox fix 回滚每个stage代表着不同的角色signoff（devdone、qa、uat、ops）
- 部署到 QA 环境测试，部署到 UAT 环境验收，部署到 Pre-Production 环境，部署到 Production 环境ASAP尽早部署，尽量真实实例：cache和apache
- 新加入的 Dev 搭建开发环境，持续集成新加入构造节点，部署给 Dev 重现 bug，Dev 需要依赖组件的节点新人、新机器，多久能跑通 build？如何快速部署指定的版本？多个 team 共用一个 Amazon 的 VPC，测试、build、showcase 等环境，支持 centos、debian。可以通过命令自动化的创建、provision、维护实际案例：10team、250nodes分布式团队开发，使用云很方便。系统设施更接近于生产环境。可以自由使用多个节点搭建环境。持续集成服务器，QA, UAT, Showcase 等测试环境，Dev使用的节点pre-production 环境，production 环境，两者一致（互相切换），使用和部署 AmazonVPC 相同的 chef 自动化部署，rundeck等辅助管理，同样的 chef 保证了产品能够顺利上线。两者之间越接近真实越好。真实案例，loadbanlancer没有，导致一些apache 配置的问题。可以使用 rundeck 等工具辅助管理。快速响应环境的需求平台标准化，屏蔽底层的硬件物理实现实现对环境搭建的可重复性可以维护环境基线，根据镜像或副本复制环境可以对环境中的每个节点进行有效监控
- 之前都有自动化了，如何自动化部署。写一个 shell 脚步？其实之前的项目也搞过。复杂， 不易维护，不能针对不同的环境，需要 QA 来部署，需要 business 来部署，需要 Ops来部署。不同的环境：单机、云、虚拟机provisioning、configuration、integrationchef-solo，chef-server，node,chef community cookbook对 chef 的测试，https://github.com/exceedhl/toft项目中：50+cookbooks：jenkins, java, apache, tomcat, rails, mySql …50+ roles：持续集成服务器、应用服务器、数据库服务器、管理服务器…
- 虚拟私有云，VPN虚拟私有网络中nagious监控基础设施，CPU、Network等new relic 监控软件，Java、DB等通过 fog 来管理Elastic Compute Cloud，Elastic Block Store
- vagrant 基于 virtualbox，可以很方便的创建本地虚拟机。使用同一套 chef 向不同的环境部署，很多工具直接支持 chef 比如 vagrant，或者只要有sshd 就可以
- 编译（打包）一次，package 和 config 分离，各环境使用相同的脚步部署，快速反馈，逐步增强信息，逐步接近生产环境。pre commit：本地提交前，静态检查，单元测试，cucumber 验收测试stage 1: package，编译，静态检查，单元测试，打包（deb、rpm），创建临时 package repositorystage 2:standalonetests，从 stage1 获取 package，jetty 运行webapp，mock其他组件、第三方组件，运行 cucumber 验收测试stage 3:stagingtests，从 stage1 获取 package，使用 chef 在 Amazon VPC 上创建节点，集成所有组件（包括第三方）运行 cucumber 验收测试stage 4:publish，将本次 build 发布到 repository，package （deb、rpm），chef，version版本及依赖stage X:deploytoX，获取对应 version 的 package、chef，一键部署到相应的环境，QA，UAT，showcasepre-release&release，获取对应 version 的 package、chef，一键部署到相应的环境，pre-production，production
- 自动化build 要快、稳定环境要逐步接近生产环境云平台、虚拟化的方便坚持原则、做正确的事情（红了不能提交、回家，快速修复或回滚）一开始就要集成、就要部署
- https://github.com/flanker/infoq-demo