公司内部和外部环境都在变化。在内部，公司需求、产品和员工都在不断调整。在外部，技术环境也在持续快速变迁。
译自 The Joys and Pains of DevOps，作者 Joanna Wyganowska 是Octopus Deploy的营销副总裁。在她的角色中，她有幸与DevOps从业者讨论与持续交付相关的最佳实践，以及从他们的DevOps之旅中吸取的教训。Joanna 是一个精益大师，并且...
“没有痛苦就没有收获”非常适用于DevOps。虽然从亚马逊首席技术官 Werner Vogels 提出的“你开发它，你运维它”的概念中获得了许多回报，但DevOps从业者也需要面对许多挑战。
DevOps最有价值的部分之一是消除阻力。Stigg的联合创始人兼首席技术官 Anton Zagrebelny 将其描述为一台运转良好的机器。他的团队能够完全自动化他们的DevOps流程，从简单的代码推送到git库，最终实现基础设施供应和软件部署。
生物技术研究公司Charles River实验室的高级DevOps工程师 Stephen Shamakian 分享了这个观点。他说，没有什么比自动化手动和单调乏味的DevOps任务更好的了。他说:"能够多年来快速可靠地进行部署是无价的。这就像赋予一个以前不存在的流程生命，现在它可以完全自主地运作。因此，它有自己的生命。"
然而，他们都承认DevOps伴随着挑战。对于 Zagrebelny 来说，是跟上内部和外部的变化。在内部，公司需求、产品和人员都在不断变化。在外部，技术格局也在不断变化。
在他看来，平衡这些动态并相应调整当前的DevOps实践是区分一个好的和一个伟大的DevOps工程师的关键。对于 Shamakian 来说，关键在于人和流程。
DevOps在很大程度上是开发、运维甚至安全团队协作方式的文化变革。尽管DevOps旨在改进这一点，但在许多情况下，这些领域仍然以站点的形式运行。有时一个领域实施的东西会阻碍另一个领域；作为DevOps领导者，您经常处于中间位置，努力找到最佳前进道路，同时也找到一个可接受的中间立场。
DevOps工程师 Matt Ash 对DevOps的烦恼和快乐提出了另一个有趣的观点。他将大规模的变化描述为DevOps最困难的部分。
他相对较小的DevOps团队需要为许多软件工程师提供服务，这些工程师构建和部署各种各样的产品。一些使用Windows，Linux，节点，C#，Python。他的团队需要准备好帮助团队前进。这通常意味着为每个团队不同需求量身定制最佳解决方案，而又不阻碍其进步。这需要在过程中学习很多，也带来了一些压力。
另一方面，他将大规模启用指出为DevOps最有价值的部分。当一个小团队可以支持大量工程师每天或每周构建和交付多次而无需任何干预时，您就会知道自己的工作做得很好。
一个设计良好的DevOps解决方案应该使团队隐形。这包括顺利路径，即部署成功，以及您支持团队解决部署问题的能力。
DevOps令人满意的一个共同要素也是: 改进开发者体验和业务结果。Climavision产品开发总监Dale Francis说，DevOps的回报来自于解决问题，因此日常操作变得简单，开发者体验也变好。
此外，作为DevOps组织的成熟还可以让每个人更多地专注于解决业务问题，而不是与技术问题作斗争。他在DevOps中看到的一个挑战有时候是过度处理事情。他的建议是保持简单，并且总是评估流程自动化的哪些部分值得时间和精力。
Octopus Deploy的创始人兼首席执行官 Paul Stovell 总结了在DevOps旅程中许多客户的经验: "实施DevOps自然会很困难，一直以我们一贯的方式做事总是很诱人。所以要接受它需要一些前期工作，要有一个清晰的最终状态愿景，并坚持通过最初的困难。结果会是值得的。"
没有痛苦就没有收获，所以在继续记住面对挑战是过程的自然部分时，收获DevOps的好处。