我们的送货团队位于 Made Tech 完全接受devops文化和思维方式, which means that we take on many more responsibilities across the software development lifecycle than just writing code. 除了建立精心设计的数字服务, 我们还为这些服务运行的基础设施的供应和管理做出贡献, 部署的自动化和运行, 并处理部署后的监控和管理. 毕竟，如果你构建了它，你也可以运行它!
但是软件交付不仅仅是提供技术输出，比如代码, 基础设施, 或者部署包. 作为软件工程师，我们也有责任关注 结果 这是我们在日常开发工作中所做的贡献. Outcomes are a great way to measure the success of a delivery because they focus on the net effect that the software we release has on our citizens and users, 而不是纯粹的技术交付物，如代码或预置的基础设施.
一旦新版本成功地投入生产，工作就不会停止, 因为我们的团队也需要确保我们已经实现了这些预期的结果. 我们认为所有这些部署后活动与开发工作本身一样重要. 换句话说，交付并没有在生产中完成.
测量结果
一旦数字服务成功上线, 我们需要了解它是否真的达到了我们的目标. T在这里 are many ways to gather this information and we find it to be most effective when the whole team is involved in this process.
当然，有几种标准的技术路线可用于收集此信息. 示例包括匿名网络和数据分析, 呼叫中心统计数据分析, 以及服务本身内置的实时反馈功能. 但它也可以来自更直接的个人来源.
We find that user research with the citizens who use the digital services we build gives us access to a deep lake of useful feedback which we can use to measure the effectiveness of these services. 我们发现有几种有效的方法，包括(但不限于)调查, 反馈形式, 直接与用户进行测试, 以及与用户研究组织在更正式的研究上的伙伴关系.
We also gather feedback from the public sector service teams who interact directly with citizens in order to understand usage patterns. 这 information gives us a strong indication of whether our services are providing the value and 结果 that we expected them to.
除了检查我们的服务是否满足市民的需求, 我们还确保它们易于操作, 易于理解，并为尽可能多的人所接受. 英国政府的指导方针 服务标准 这是进行这种分析的一个好的起点吗, and we recommend that anyone with an interest in measuring their 结果 in the public sector reads through this standard.
进化和增强
Software projects are akin to living entities in that they require constant nurturing throughout their lifecycle, 包括部署后阶段.
一旦我们整理了测量阶段的所有数据, we have a set of high-quality data points which help us to understand whether the expected 结果 have been achieved. 遵循精益原则, 我们能够使用这些学习反馈到下一个交付周期. 这有助于我们确保我们总是在构建之前进行测量.
另外, it is sometimes necessary to consciously take on a bit of technical debt during the development lifecycle. We find that post-deployment is a good time to analyse if t在这里 are major debt items that need to be tackled. 在进入下一个构建阶段之前，要特别考虑这些事项, as letting technical debt pile up can lead to fragile systems that are hard to change and take longer than they should to enhance.
We make this process easier for ourselves by ensuring that we keep a log of our decisions to take on technical debt during development. 然后，我们会尽快、尽可能频繁地处理这笔债务. Doing so ensures that we consistently maintain the stability of the digital services that we build to serve our citizens.
技术债务, 从数据中学习, 用户测试和战略性组织目标都有助于推动我们的未来路线图, 无论是期望的结果还是技术上的可交付成果.
监控-性能和主动性
The primary outcome we strive for is to build services which help public sector organisations to better serve citizens. 虽然功能的交付很重要, 如果一个数字服务的交付时间过慢，可靠性低，那么它就不是一个有用的服务.
这 means that our teams are responsible for ensuring that the services they build are both performant and reliable. 虽然这是我们在开发阶段非常关注的事情, it is also extremely important to make sure that these metrics are logged and monitored post-deployment, 因为这是系统经历真实负载水平和使用模式的时间.
例如, 我们将始终确保我们有自动记录, 监控和警报到位，并在部署后持续监控这些数据流. 我们倾向于在构建监控时考虑先发制人的警告, 这意味着我们经常可以在问题发生之前发现并解决问题.
这种部署后对性能和可靠性的关注也延伸到了代码库. It is often easier to analyse your code with a fresh set of eyes once a production delivery is completed. 这, 与从监控机制收集的统计数据配对, gives us a strong set of data points to plan performance- and reliability-related codebase enhancements.
You can find more detailed information about our approach to monitoring and production-readiness in our Productionisation清单.
持续关注安全和隐私
Public sector organisations have an extremely important responsibility to ensure that both the security and privacy of citizens are maintained throughout their I.T. 基础设施和服务. 因此, the developers who build these services must collaborate with security teams on an ongoing basis to make sure what they build is as attack-proof as possible.
这 responsibility can range from keeping support software and operating systems up to date with security advisories, 提供安全漏洞监控, 实现和部署任何所需的软件级安全性增强.
我们通常使用的一些方法来维持严格的安全标准，包括:
- 建立威胁模型，以建立对我们试图减轻的风险的共同理解.
- 使用诸如Dependabot之类的工具实现自动化的依赖漏洞检查.
- 对云服务和系统访问应用最小权限原则.
- 尽可能在网络、环境和容器之间保持强隔离.
- 必要时引入外部安全团队对我们的服务和基础设施进行渗透测试.
授权内部开发团队
从客户的角度来看, t在这里 is always a danger when outsourcing development to external vendors that they will build your software with a “fire and forget” mentality. 在这些情况下, your software becomes legacy software as soon as the vendor signs off delivery and moves on to their next engagement. 这 leaves you in a predicament w在这里 you are unable to maintain or enhance your digital services without either relying on the vendor who initially delivered them, 或者在你试图自己维护它们的时候给你的组织带来风险.
We believe that this (sadly common) approach is not only counter-productive but also extremely unscrupulous on the part of software vendors. The services we build affect many people’s lives every day and we have a responsibility to make sure that they are managed by teams who have a clear understanding of how to maintain and upgrade them, 即使我们不再直接参与其中.
In an ideal scenario we prefer to work in collaboration with in-house developers during the development process, 但这并不总是可能的. 无论哪种情况, 如果我们在成功地管理了一个“最终”产品发行版后转移到其他项目, 我们必须提供一个完整的, 全面移交给将继续维护和升级我们构建的服务的团队. 这在交给内部团队和其他外部供应商时同样重要.
Techniques for ensuring that this handover is managed smoothly and effectively can include the provision of sufficient (but not excessive) documentation, 为接管代码库的团队提供培训课程, 以及正式的交接会议.
我们还发现，我们对DevOps和自动化的关注简化了移交过程. The fact that aspects such as automated regression testing and continuous delivery are implemented as part of our delivery typically lowers the volume of information required for handover, 这降低了接管我们所构建的服务的团队的认知负荷.
最终的想法
Our responsibilities as software delivery professionals extend well beyond the build and deployment phase of the software delivery lifecycle. 当遵循构建-测量-学习反馈循环时, 您不应该将部署阶段视为最后一步, 而是作为成功交付下一阶段的垫脚石.
这 approach will allow you to go above and beyond as a delivery organisation and to consistently exceed your customers’ expectations. 它使您能够提供可持续的技术，实现您期望的结果, 无论是现在还是将来.
如果你想从我们的博客中了解更多，你可以访问我们最近的帖子 在这里.
