Azure云中Web应用的持续集成实践

由于从事的工作领域关系，目前会或多或少的关注DevOps课题的相关领域，当然目前还在尝试多种适应于持续开发持续集成领域的工具和组合方式，个人粗浅的领会是DevOPS其实既不会只是开发者需要关注的，也是运维人员应该关注的领域，因为未来的IT世界其实是个”相对混合”的空间，发展之快超出想象；在开发测试领域的工具上看，Chef/Puppet/PowerShell DSC，到开源领域广泛应用Salt Stack, Ansible到 Docker生态圈等封装一系列基础架构即代码等概念的涌现，无时不刻的不在提醒我们演进背后的力量的本质，是业务对IT系统的能力持续提高，举例来说需要通过持续开发，持续集成的方式实现应用功能，代码迭代更新敏捷性的快速提升；为了实现这些目的，大量的互联网公司已经开始率先进行了实践，当然不一定是全栈的实践；但是至少在某些领域已经积累了大量的经验，并且开始向下一个拆分大的应用结构到细微Restful API结构，独立运维和扩展，并且通过网关集群来交付的微服务结构；在这样大的领域变革激荡的演化过程中，对于开发运维环境的改变不能原地踏步，逆水行舟不进则退；如果现在还仅仅满足于点几下鼠标或者期望在复杂的IT系统中探索标准化IT服务，显然有些落伍；这可能不是”生存”或是”毁灭”的问题，这是一个博弈才有机会参与的时代，所以愿意或者不愿意，身为IT从业者可能都不得不去开始探索和学习的。最初的持续开发和集成的实践，我觉得先要从工具选择上开始；要想做到高度自动化必须从大道至简的原则出发，开发，过渡环境及生产环境的产生和变更，可以根据代码Build版本控制变更或初始化触发的发布流程，辅以一套参数化结构通过简单声明式的封装（类似开源领域的yml文件，PowerShel DSC的配置文件，亦或是Azure中的ARM模板，亦或是Dockerfile当然也可能是Chef 的菜单rb配置），通过标准化的Provider驱动对于配置的跨环境标准化执行流程；一个持续集成的雏形就出来了；逐步到上层结构辅以审批，资源注册，生命周期管理及跟踪等，那么一个较为丰富的开发测试DevOps技术工具栈逐渐补全了；最后就是从应用开发端逐渐向微服务架构设计演进的过程；最终需要实现的效果自然是将持续开发，持续集成；适应业务快速的扩展和功能的迭代，减少由于基础结构性是失却，配置变更不到位或者大规模的回归性测试造成的整体回滚等一系列问题引发的对业务端的拖累和影响；所以其实挑战也是机遇，为什么曾经一度淘宝业务系统蓬勃发展也带动了的各路“花名在册”的大神风起云涌，为啥现在开源时代又造就了那么多的大师？为啥现在身为一个IT的运维人员推崇却是Python等语言和框架？这一切背后的力量作为从业者感受到了吗？如果是，那么勇敢的人总会有机会尝试并最终站在结构性的高峰的，总之，我信了…

言归正传，这里以Azure国际版为例；试图描摹一个简单的持续集成的过程实践，该过程将从本地Git或GitHUB源代码控制和存储库工具持续集成Web应用发布更新到Azure中，当然利用Azure也可以在生产和过渡环境切换回滚；需要说明的是Azure公有云发展非常迅速，除了这里所用到的网站应用以外，对于移动应用，API应用甚至是微服务逻辑应用均可以借助微软的App Service与包括上述Git源码控制库之外的如Codeplex，TFS，Bitbucket等集成。

步骤1，在本地完成

首先，我们先要确保本地的Git环境已经可用，根据你的系统是Windows还是MAC的选择相应的Git客户端。

接下来，打开本地的Git环境，Windows的可以直接用GitBash

创建我们的测试WEB项目目录，进入并初始化本地Git库，

cd C:/Users/shzhai.FAREAST/Documents/GitHub/TestWebCIRepo

git init

我们的项目做个最简单的就好，力求只是为了测试代码发布和持续集成过程，所以这里我们先在项目里创建一个默认静态页面，

echo “My Demo page!” > ./index.html

现在添加页面到本地的Git库中，

git add ./index.html

我们提交改变并添加注释到本地库，

git commit -m “Add the first static page to local repo!”