手机网站相关,给个网站可以在线,wordpress 安装语言设置,wordpress采集商品这应该算是《Git企业开发者教程》的篇外篇#xff0c;介绍一下这个教程是怎样写出来的。相信每个技术人都有类似下面的文件夹#xff0c;保存着你辛苦工作的成果。实际的感觉#xff1a;看着闹心#xff0c;弃之不舍。一份文档久经修改#xff0c;不能定稿#xff0c;循环… 这应该算是《Git企业开发者教程》的篇外篇介绍一下这个教程是怎样写出来的。相信每个技术人都有类似下面的文件夹保存着你辛苦工作的成果。实际的感觉看着闹心弃之不舍。一份文档久经修改不能定稿循环往复结果就是一系列的v1 v2 v3 ……这当然还是习惯比较好的技术人习惯不好的估计一个项目下来各种文档存得哪里都有最后自己都找不到了。既然要写git教程当然不能用这种方式来写不然我都好意思拿出来给大家看。技术文档的编写其实和普通的文档编写有很大不同因为里面的每个细节都很重要最好能够像管理代码版本一样进行跟踪对于项目/产品文档你还可能会同时维护多个版本这非常像我们日常的编码过程。这也是为什么很多技术人开始选择使用Markdown来编写文档。DevOps 文档中心 v0.52016年3月的时候我曾写过一篇 《拯救你的文档 – 【DevOps敏捷开发动手实验】开源文档发布》的博客算是我对这种新的文档编写方式的第一次尝试当时使用的是基于Phyton RestructureText和Readthedocs的引擎。这份文档至今仍然托管在github和readthedocs.org上面算是对当时尝试的一种纪念https://vsalm-hols.readthedocs.io/zh_CN/latest/当时的这个做法应该算是 DevOps 文档中心 的雏形v0.5版本。后来我的团队在2016-2017年间的客户项目实施公开课培训和企业内容过程中先后编写了一共超过20套培训文档分布在超过40个Git存储库中以下只是列出一些比较成体系的并还存在于最新版文档中心内的– 微软云端开发训练营– 基于Docker的DevOps实战培训微软研发云版– 基于Docker的DevOps实战培训开源工具版 GitLab Jenkins ELK– Docker 实战– Apache Mesos 实战– Jenkins 实战DevOps 文档中心 v1.0这些文档后来被我们整合成了 DevOps 文档中心基本上就是用了一个索引页将所有的文档入口连接到一起。就成了下面这个样子这算是文档中心第一次成型v1.0版本。当时我写了另外一篇博客 《Markdown/reST 文档发布流水线》介绍了我们的一些做法包括使用 docker 进行 rst 文档的生成并使用 Visual Studio Team Services 发布流水线进行自动化发布。同时我们也开始借助这些文档配合我们的 DevOps 实验室 提供线上/线下的实战培训取得了非常好的效果关于 DevOps 实验室 随后我会单独写一篇博客介绍它的技术架构和我们的DevOps实践。DevOps 文档中心 v2.0上面的做法基本上满足我们日常技术文档编写维护多版本发布需求但是也存在一些问题比如文档格式使用的是RestructuredText我相信很多人都没有听过这个格式这个格式是Python中用于编写文档的格式语法和Mardown非常接近。2017年我们 LEANSOFT 团队加入了很多新人大家都对单独学习一种新的语法有抵触。我自己也不希望我们采用和社区不同的标准这样会让未来的维护成本越来越大。文档库规模越来越大我粗略统计了一下截止2017年12月我们大概编写了超过2000页的rst文件总代码行数超过200,000行其中还包括大量的图片资料。这些内容都散布在超过40个git存储库中总数据量超过2个G。这40多个Git存储库每个后面都连接了一个TFS的发布流水线。这让管理起来成本很高经常会有同事来问我应该哪个个库而我自己也很难搞清楚了。定制困难在v1.0的过程中我们虽然剥离了Readthedocs的引擎仅仅保留sphinx工具来转换rst到html简化了我们的TFS发布流水线但是这个引擎很难定制。特别是我不希望团队还需要学习python才能完成定制。我们希望后续在文档中心中提供诸如DevOps 实验室集成在相关文档上直接一键创建对应试验环境并开始试验。留言/讨论允许用户留言并针对内容进行讨论基于以上这些诉求我们开始规划 v2.0。最后我们决定采用MDWIKI来直接通过js转换md为html这样就避免了在构建的时候进行文档格式转换可以与大家在github上发布文档的方式高度统一同时因为全部前端技术实现定制也更加容易。大型Git库的问题我们暂时采用git submodule的方式来将多个库进行整合这样可以避免使用多条TFS发布流水线。这个过程要特别感谢我同事厉晓明在其中做了大量工作。当前的 DevOps 文档中心 v2.0 的工作方式如下图核心git repo现在只有两个 home和mdwiki分别承载首页和mdwiki的解析工作所有的文档都在独立的repo之内通过git submodule的方式即成到mdwiki的存储库这个做法解决了2个问题大家通过submodule的引用关系就知道了文档结构并能找到对应的git仓库主库大小得到控制数据仍然存放在子库只是在构建发布的时候才集成进来主站点TFS发布流水线负责将home/mdwiki发布到Azure的App Service中的不同应用Github的TFS发布流水线负责将分库的内容双向到Github上的lean-soft账号下面使用双向同步是为了能够从社区接受pull request为未来添加留言和评论留出实现的地方。大家看到的效果就是这样DevOps文档中心首页https://docs.devopshub.cn/home(点击阅读原文即可访问Git企业开发者教程发布页https://docs.devopshub.cn/mdwiki/#!docs/g4e/index.mdGithub库https://github.com/lean-soft/devopshub-docs-g4e以上便是 DevOps 文档中心在过去一年中的演变当然现在的实现仍然存在问题比如文档中心的导航仍然需要收工维护这个问题我们打算使用构建中自动扫描文档标题的方式来解决。我们是中国最好的DevOps实施团队我们不仅会讲DevOps我们更能做DevOps持续改进中。原文地址:http://devopshub.cn/2018/01/07/devops-docs-practise/.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
