持续交付的 What、Why 及 How
Kohsuke Kawaguchi（KK）于2004年开发了 Jenkins 项目的前身（Hudson），一开始就是为了解决他自己的关于自动化的需求。他自己也没想到13年后，Jenkins 成了软件交付过程中的核心工具，驱动着千万企业的持续交付与 DevOps 过程。
相关分享
如何建立你的离岸交付团队？
这里有四种离岸交付合作模式：Team Extension Model，Hybrid Collaboration Model，E2E Collaboration Model和Onshore/Offshore Collaboration Model。每种模式都有其优势和挑战，需要根据组织自身情况选择合适的模式。其中E2E Collaboration Model是一种全面的离岸交付模式，适用于团队成熟度较高、业务模块相对独立的情况。
无图
敏捷交付的工程效能治理
在Thoughtworks，我们通过对最佳实践(Sensible Default Practices)、能力和度量的持续治理和改进，在保障交付正确的客户价值和减少浪费的基础上，使交付质量更好，速度更快，反馈更及时，从而达到追求工程卓越和形成发展工程师文化的目的，最终产生客户影响力。
无图
How to find the corresponding session in MogDB/openGauss from OS thread ID
当MogDB数据库由于某种原因占用了较大的系统负载，比如CPU占用接近100%，那么如何知道到底是数据库里的哪个会话或者哪些会话占用了资源？
在Oracle数据库中，这样的问题诊断，通常都会关联 v$session, v$process, 以及操作系统top命令或者ps命令中查到的操作系统进程ID。
但是MogDB本身是线程模型，在操作系统上只能看到一个进程号，那么该如何定位问题？
无图
How to make Total Commander works with Everything and QuickLook
大多数时间我的工作是在自己的Macbook Pro里完成的，但是因为主要用于游戏的Windows配置了较大的屏幕，有时候也还是会顺手在Windows上进行工作。那么如何让Windows操作系统用起来更顺手？
无图
无图
无图
提升软件交付效能——初探“按需发布”
在精益思想的指导下，团队寻找开发流程中的阻碍点，并从各个层面做出调整策略。在业务侧，分析哪些需求可以做到按需发布，哪些需求无法做到，设定适合团队的按需发布标准，并调整迭代工作量。在开发侧，考虑数据的兼容性，部署方式，以及高频率部署所带来的环境准备问题。在测试侧，提高自动化测试的运行速度和主流程的覆盖范围，并利用平台自身的自动化测试覆盖率统计功能，查缺补漏。
无图
软件交付效能度量——从吞吐量和稳定性开始
除了感性的工作体验外，我们还需要指标来度量改进措施是否对提升软件交付效能有帮助。过多的指标会对团队造成不必要的管理成本，也容易让团队失去关注焦点。从吞吐量和稳定性两个维度考量的四个关键指标是简单但有效的指标，建议优先度量。
无图
敏捷度量的Why、What、Who、When
敏捷不仅有度量，度量还是敏捷项目非常重要的一部分，但敏捷度量和传统的度量存在很大的区别。敏捷度量不是以评估和考核为目的的，它是为了帮助团队拉通目标和行动、指导指定工作计划和任务、协助团队持续改进而发生的。
无图
敏捷交付中的自动化测试
在提及自动化测试的时候，很多人会把工具的使用等同于自动化测试。自动化测试应该是一个策略性的系统化工程，不只有自动化工具。自动化测试要发挥其频繁快速的质量反馈作用，还需要团队从文化和技术上去建设和学习。
无图