1. 应用的交付

在进入互联网这个行业以来，很长一段时间我理解的应用交付就是程序的安装部署，把业务方给我的程序安装包运行起来就好了。但是，随着在这个行业中逐渐的摸索，我对交付有了新的理解，我认为交付就是将需求转化成某种介质提供给需求方，以达到提供服务能力并创造价值目的的过程。而应用交付的对象是应用更加具体，更侧重于软件的需求交付，但也不仅局限于程序的安装部署了。

应用的交付可以有多种形态。互联网企业或业务团队成立的初衷是实现一些想法或者目标，比如想要即时通讯 IM工具，想要使用电商平台，想要提供互联网检索功能等等。企业创始人或业务负责人给到业务团队的需求是明确的，就如需求目标就是想要一个即使通讯的工具来支撑整个集团的高效沟通，但是业务团队如何实现并交付这样的需求其实是不固定。当然，可以选择从新开发一个新的通讯IM工具来交付这个需求，更可能的情况确是提供一套解决方案采购其他厂商已有的产品，两种方式都是可以满足最初的需求交付，只是满足需求的方式或者说介质不同了罢了。交付需求的介质可能是打包的程序、代码函数、API接口、公有云产品、解决方案、设计图稿甚至是 Markdown 文档等等，只要能满足的需求方的需求即可，并不局限于固有的意识形态。

随着时代技术的演进，应用交付的载体也在不断的变化以满足不同的交付场景，通过对交付过去、现在和未来的方式进行分析，以便对应用交付有更加深入的理解。

• 在 《应用的交付形态与发展》 一文中梳理了应用交付的发展过程以及未来的可能推测。

1.1. 总结

通过多年的经验对交付有了更深刻的认识理解，交付的目的是交付需求，而需求的交付方式是多种多样的。当需求需要使用应用来交付时，从应用交付方式的演进来分析过去、现在和未来的交付方式。由于交付方式的不同，对应用的定义也有所不同，核心主要是应用运行的平台、开发的语言、运行文件封装方式、配置及环境信息以及说明性的材料。

结合以上的内容，总结了几点建议：

• 如果业务比较早期，专业人员未就绪，可以选择 docker/docker-compose 进行基础的容器化封装运行。
• 如果团队有懂 Kubernetes 的技术人员，就使用 Kubernetes 的方式管理服务。
• 如果是在线业务或开发测试环境，可以使用 CI/CD 的方式持续集成部署，Jenkines 还是目前的主流技术选型。
• 如果是离线业务，或安全限制等，推荐使用 Helm Chart 的方式封装应用。
• 如果团队技术前沿，有平台支撑，可以使用 Serverless 的方式定义交付需求，或者使用低代码或无代码来开发产品。
• 总之，企业应该结合业务场景与技术能力来选择合适的应用定义与交付方式。