阿里云专家将通过DevOps与阿里云容器服务、持续集成、运维三大块来为大家讲解。
DevOps与阿里云容器服务
1. DevOps与阿里云容器服务（一）
DevOps（英文Development和Operations的组合）代表一种文化、运动或实践。旨在促进软件交付和基础设施变更软件开发人员（Dev）和IT运维技术人员（Ops）之间的合作和沟通。它的目的是构建一种文化和环境使构建，测试，发布软件更加快捷，频繁和可靠。
本文是整个系列中概念最多的一篇，后续大部分会以具体的场景为主，面对不同场景，要根据自己的需求、公司研发人员的能力、规模来进行选择。
2. DevOps与阿里云容器服务（二）
DevOps没有规定什么样的流程是一个标准的流程，因为DevOps的方案是随着你的业务场景、人员的能力、软件开发的复杂度、公司的规模等等变化而变化的，只有对于自己的业务与场景而言的合适与不合适，在本系列文章中将会和大家一起讨论一些常见的DevOps的实践与方案，供大家参考。
在本文中，将会通过一个简单的例子来介绍使用阿里云容器服务进行containerOps的实践与经验。
3. DevOps与阿里云容器服务（三）
你若问十个哲学家什么是『哲学』通常你会得到十一种答案（有一种是你自己的）。
你若问十个持续交付布道师什么是『DevOps』，你恐怕得到的是上百种答案（因为你自己也有好几种）。
只有一个哲学问题是严肃的，那就是生与死。
而对于DevOps只有三个问题是严肃的
而今天我们要谈的是如何安全的部署你的系统，部署这个名词包含了很多的含义，最简单的解释就是如何让你的程序运行在最终的环境上。但是部署的方式上面有非常多的最佳实践。接下来我们来讨论下常见的几种发布方式，以及这些发布方式和容器结合的使用。
4. DevOps与阿里云容器服务（四）
大于大多数场景而言，对客户提供服务的软件的形态有三种。一种是前端类服务，用户可以直接或者间接通过网页、接口调用使用该服务提供的能力；一种是后端类服务，用户无法直接使用该服务提供的功能，该服务主要的使用者是其他服务，并通过其他服务最终将处理后的结果反馈给用户；第三种是调度任务类服务，即不被用户使用也不被其他服务调用，它的生命周期只存在在一个任务的执行生命周期中，通常任务的执行周期完毕，服务的生命周期就停止，通常为无状态资源密集性服务。
对于上述三种场景，以路由权重切换为主要实现方式的发布策略例如蓝绿发布、A/BTest等通常情况下比较适用于前端类服务与后端类服务。下面我们用一个简单的例子来拆解下如何使用阿里云容器服务来实现这两类服务的蓝绿发布。
5. DevOps与阿里云容器服务（五）
还记得第一次听说性能测试这个词是在大学二年级，刚刚进入实验室，老师将一本Load Runner的书籍放在桌子上，告诉我用这个工具测试下学校课程网站的性能。相当长的时间内，对性能测试的理解就是用一个类似Load Runner的工具，然后通过工具得出一些指标，就可以交工了。但是实际上性能测试是一类测试的统称，而压力测试是最常见的性能测试的一种，性能测试(广义)还包括负载测试、并发测试、可靠性测试等等。
在本文中，今天主要讨论的是压力测试、负载测试与并发测试，对于大部分的应用来讲，这三种测试已经可以满足基本的需求了。
持续集成
1. 基于容器服务的持续集成与云端交付（一）- 交付之禅
随着微服务架构与容器虚拟化技术的发展，持续集成与持续交付的概念又重新回到了大家的视野，越来越多的公司开始使用持续集成的系统来解决频繁发布带来的质量问题；使用持续交付的工具来实现代码在不同环境上的自动部署。原本有些学院派乌托邦式的思想正被千千万万次的集成与部署证明着它应有的价值。那么究竟是因为什么让持续集成与持续交付这个已经不再年轻的软件开发与交付的思想重新焕发绽放迷人的光彩呢？
2. 基于容器服务的持续集成与云端交付（二）- 多维度打磨交付能力
当我们将一个系统通过云端容器交付的时候会发现不能单纯的将Docker作为一种交付工具来对待，更多的时候是作为一个交付平台的基础设施来看待，还需要关心的是使用Docker后网络、存储、安全、性能、监控等等不同方面带来的变革。
因为交付的本质是将一套复杂的软件系统从零到一完成开发、测试、部署、上线的过程，软件的复杂度直接关系到了交付的难度，特别是现在微服务的架构方式越来越成为主流，给交付也带了更多的挑战。
我们不仅要考虑一个系统交付的环境，而且还要考虑针对特定的软件架构，交付系统的网络、存储和安全等等是否能够满足需求。本文中将会针对上面提到的内容，分享我们是怎样从以上几个方面打磨交付能力。
3. 基于容器服务的持续集成与云端交付（三）- 从零搭建持续交付系统
对于大多数公司而言，选择一个合适自己的持续交付系统是尤为重要的一件事情，不同的公司、不同的业务使用的场景也各不相同，因此要根据自己的业务场景与发展方向来选择合适的方案。
本文将介绍根据不同的业务场景与交付方式，阿里云容器服务提供了哪些种持续交付方案。
4. 基于容器服务的持续集成与云端交付（四）- 多种发布方式
哲学有各种各样的流派，百家争鸣，但是只有一个哲学问题是严肃的，那就是生与死。而云端交付过程中也只有三个问题是严肃的。
- 如何重建你的系统 How to recreate your system？
- 如何安全地部署你的系统 How to safely change your system?
- 部署后的问题监控与解决 When something has gone wrong?
如何安全的部署你的系统，部署这个名词包含了很多的含义，最简单的解释就是如何让你的程序运行在最终的环境上。但是部署的方式上面有非常多的最佳实践。接下来我们来讨论下常见的几种发布方式，以及如何利用容器发布实现最常用的零宕机发布方式蓝绿发布。
5. 基于容器服务的持续集成与云端交付（五）- 探究持续交付系统的本质
在这篇文章中，我们会用一个不一样的角度来思考持续交付，到底持续交付给我们带来了什么，在容器的持续交付的场景中还缺少什么。
6. 使用阿里云容器服务Jenkins 2.0实现持续集成之the tag you want篇
最近收到很多有关于持续集成场景中image tag的反馈，例如，每次image build的时候希望“Jenkins”能够给image标上不一样的tag，部署应用到阿里云容器服务希望Aliyun-Container-Service-Deploy插件能够实现不是每次以固定的tag发布。本文在原来的持续集成场景中增加这样的两种能力：根据git SHA和构建时间来给image打tag，支持环境变量和compose模板配合部署应用。
为了简洁起见，本文将上述两种能力在一个持续集成场景中进行运用。整个场景是，在代码中增加环境变量配置文件，代码变更触发自动构建，打包代码，构建镜像（用git SHA和构建时间tag image），推送镜像，使用环境变量文件和compose模板来部署应用到阿里云容器服务。值得说明的是，真实的业务场景都是复杂的，需要大家根据自己的业务需求量体裁衣。
7. 使用阿里云容器服务Jenkins实现持续集成和Docker镜像构建(updated on 2017.3.3)
持续集成作为敏捷开发重要的一步，其目的在于让产品快速迭代的同时，尽可能保持高质量。每一次代码更新，都要通过自动化测试来检测代码和功能的正确性，只有通过自动测试的代码才能进行后续的交付和部署。本文主要介绍如何将时下最流行的持续集成工具之一的Jenkins结合阿里云容器服务，实现自动测试和镜像构建推送。
8. 使用阿里云容器服务Jenkins实现持续集成之GitLab篇
本文将介绍如何使用阿里云容器服务搭建GitLab作为代码管理仓库并使用Jenkins插件部署应用，同时支持蓝绿发布和标准发布两种策略。
9. 使用阿里云容器服务Jenkins 2.0实现持续集成之Pipeline篇(updated on 2016.12.23)
我们在定义一个Jenkins项目的时候，希望它是一个清晰的范围。也就是说，如果这个项目叫mvn test and build，我们就应该在脚本里实现测试和jar/war包打包。而事实上是，接下来的需求很多时候是把测试结果展示出来，还有上传jar/war包。这个时候，Devops工程师会陷入一种纠结，就是值不值得为了这个需求再重新创建一个freeStyle的项目。明明可能只有两个语句，却需要整个重新配置一个项目。新建意味着付出更多的精力并且后期维护成本增加；在原有的项目里实现，意味着项目臃肿，定义模糊。
本文将介绍一个Pipeline项目如何实现代码提交并触发测试，测试结果展示，war包本地存储以及上传OSS，构建镜像，部署应用，邮件推送结果的持续交付方案
运维
容器服务slack运维机器人
几年前开始创业，组建团队的第一天，我们首先讨论和考虑的不是高屋建瓴的业务场景和目标，而是整个团队的协同和沟通的问题。选择使用什么作为团队的IM，选择什么作为BUG的记录，选择什么作为需求的跟踪，这些基础设施的存在无形中提高了整个团队的生产力，保证了协作的顺畅和流程。由于团队的成员有些是外国人，而在国外GEEK圈中风光无限的SLACK也就顺理成章的被老外们安利到了团队中。
那么slack是个什么东西呢。
其他
容器服务 Container Service
容器服务提供高性能可伸缩的容器应用管理服务，支持用Docker容器进行应用生命周期管理，提供多种应用发布方式和持续交付能力并支持微服务架构。
本文为云栖社区原创内容，未经允许不得转载，如需转载请发送邮件至[email protected]