ci /cd
My first job out of college was for a large software company. We had major annual releases of our flagship product and minor releases every month or so. We followed a traditional software release cycle.
我大学毕业后的第一份工作是在一家大型软件公司工作。 我们的旗舰产品主要发布年度版本，每个月左右发布次要版本。 我们遵循传统的软件发布周期。
Our customers were used to it. They chose whether or not to take an update. They were in control. That was a little scary since we were the vendor — not them.
我们的客户已经习惯了。 他们选择是否进行更新。 他们控制住了。 因为我们是供应商，而不是他们，所以这有点吓人。
We decided to make a move toward CI/CD, turn the process on its head, and take a modern approach to software development. As soon as a product feature is complete and tested, push it into production.
我们决定朝CI / CD迈进，扭转这一进程，并采用现代方法进行软件开发。 产品功能完成并经过测试后，将其投入生产。
Sound good? It is, but that’s just the tip of the iceberg. There is so much more that goes into providing a high-quality experience to your end-users.
听起来不错？ 是的，但这只是冰山一角。 为您的最终用户提供高质量的体验还有很多。
设定期望 (Set the Expectation)
When moving from a traditional software release cycle to CI/CD, you might be surprised to find just as much pushback from people internally as you find externally from your customers.
当从传统的软件发布周期过渡到CI / CD时，您可能会惊讶地发现，内部人员与客户外部人员的回撤一样多。
People don’t like change. It’s human nature. Give someone a routine and they will be happy. Moving to continuous deployment is like telling somebody, “Everything you’ve done up to now is wrong. Please relearn all of it.”
人们不喜欢改变。 这是人的本性。 给某人一个例程，他们会很高兴的。 进行持续部署就像告诉某人：“到目前为止，您所做的一切都是错误的。 请重新学习所有内容。”
内部斗争 (Internal struggle)
Inside your company, you’re going to get pushback from all sides of the org. They have to rework customer contracts. They don’t understand how something could make it to production without a full regression testing cycle. They don’t trust the developers to not break everything.
在公司内部，您将得到组织各方面的支持。 他们必须重做客户合同。 他们不了解如果没有完整的回归测试周期，某物将如何进入生产。 他们不相信开发商不会破坏一切。
There are going to be hiccups. You have approximately a 0% chance of pulling it off without a hitch on your first try. That is OK. Set the expectation that processes are changing and you’re ironing out some of the details.
将会打h。 您有大约0％的机会将其顺利拉出，而无需进行任何尝试。 那没问题。 设定流程正在发生变化的期望，然后您将消除一些细节。
客户期望 (Client expectations)
Your existing customer base is accustomed to you behaving a certain way, but you’re now going to change the way you operate to something “better.” You are going to have to prove to your customers that this new model is better than what you’re doing right now.
您现有的客户群已经习惯了您采取某种特定的方式，但是现在您将要改变运营方式，使其变得“更好”。 您将必须向客户证明这种新模型比您现在所做的要好。
You must convince them this is going to be worth changing their process for. This is your chance to prove that defect turnaround gets exponentially quicker. There’s no more waiting for a specific date to see a fix. Once the change has been made, it’s in their hands.
您必须说服他们，这将是值得改变他们的过程的。 这是您证明缺陷周转速度更快的机会。 不再需要等待特定的日期才能看到修复程序。 进行更改后，就在他们手中。
抛开“释放”一词 (Ditch the Word “Release”)
When you switch to CI/CD, a standard release model goes out the window. Instead, you must focus on small incremental changes since every code push is going to production.
当您切换到CI / CD时，标准发布模型就会消失。 相反，由于每次代码推送都将投入生产，因此您必须专注于小的增量更改 。
There are no more “releases” with this method of deployment. You aren’t going to be shipping an updated version of your product that has a year’s worth of changes in it anymore. Instead, you will be delivering tiny pieces of functionality, bug fixes, enhancements, and features daily.
这种部署方法不再有“发行版”。 您将不再要交付产品的更新版本，而该版本具有一年的更改价值。 取而代之的是，您每天将交付微小的功能，错误修复，增强功能。
The cadence doesn’t need to be set. Whenever the developer finishes the code and the QA approves it, ship it. That could mean once a week or it could mean five times a day. The idea is that when it’s ready, it’s available.
不需要设置节奏。 每当开发人员完成代码并由质量检查人员批准时，就将其寄出。 这可能意味着一周一次，也可能意味着一天五次。 想法是，准备就绪后就可以使用。
You will need to figure out how verbose you want to be with your “release notes.” Since you aren’t pushing out releases, do you need them anymore?
您将需要弄清楚“发行说明”的详细程度。 由于您不发布发行版，因此您是否需要它们了？
Some companies have a tech writer dedicated to the development team. With each code push, the tech writer will come up with a brief, user-friendly description of what changed. The description is pushed to the “What’s Updated” page, which is broken down by day.
一些公司有一位技术撰稿人致力于开发团队。 每次推动代码时，技术编写者都会对更改内容进行简短，用户友好的描述。 该说明将推送到“每日更新”页面。
There are many ways to do release notes, and none of them are better than others. Do what works best for your company.
有许多种发布说明的方法，但没有一种比其他方法更好。 做最适合您公司的事情。
强调自动化测试 (Emphasize Automated Tests)
The breakneck speed of CI/CD doesn’t allow for a manual smoke test of your application with every change. It would be impossible to keep up with the changes.
CI / CD的快速速度不允许您对应用程序进行每次更改都进行手动烟雾测试。 跟上这些变化是不可能的。
To instill confidence both internally and externally to your organization, you must build up a suite of automated tests that run whenever a change is made. Automate the smoke tests you would have done manually. They are completed significantly faster. Plus, it removes the possibility of human error.
为了在组织内部和外部树立信心，您必须建立一套可以在进行更改时运行的自动化测试。 自动执行您本应手动执行的烟雾测试。 它们的完成速度明显加快。 另外，它消除了人为错误的可能性。
On my team, we run two sets of automated tests with every code change. First, we have a robust set of unit tests that exercise the code. They test the success and failure paths for every function in our codebase. If the unit tests fail, the build fails — which means our changes do not get deployed.
在我的团队中，每次更改代码后，我们都会运行两组自动化测试。 首先，我们有一组强大的单元测试来执行代码。 他们测试我们代码库中每个功能的成功和失败路径。 如果单元测试失败，则构建会失败-这意味着我们的更改不会部署。
If the unit tests pass, we move on to integration tests. We have built a strong set of Postman collections that run through the standard business processes in our app. These test all the business flows our app supports and they are constantly evolving. Once again, if any of these tests fail, our build fails — and nothing gets deployed.
如果单元测试通过，我们将继续进行集成测试。 我们已经建立了一组强大的Postman集合，这些集合通过应用程序中的标准业务流程运行。 这些测试测试了我们的应用程序支持的所有业务流程，并且它们还在不断发展。 再一次，如果这些测试中的任何一个失败，我们的构建都会失败-并且不会部署任何东西。
Only when all unit tests and integration tests pass do we know that we didn’t break backward compatibility or affect another component of the application adversely.
只有当所有单元测试和集成测试都通过时，我们才知道我们没有破坏向后兼容性或对应用程序的另一个组件产生不利影响。
Automated tests are a “build once, test forever” investment.
自动化测试是“一次建造，永远测试”的投资。
With a little bit of upfront cost, you can guarantee that a specific business process will always work when you make changes in your app. When you make production pushes five times a day, having that kind of confidence is an absolute must.
只需支付少许前期成本，就可以确保在您对应用程序进行更改时，特定的业务流程将始终有效。 当您每天进行五次生产推送时，绝对有信心。
知道当事情出错时该怎么办 (Know What to Do When Things Go Wrong)
Let’s say a developer pushed a code change that caused a system outage. The automated tests hadn’t been updated to test the scenario, so it snuck by and made it into production.
假设开发人员推送了导致系统中断的代码更改。 自动化测试尚未更新以测试场景，因此它悄悄地投入生产。
Do you revert the change? Do you find a fix and push another change?
您是否还原更改？ 您是否找到修复程序并推动了另一项更改？
With CI/CD, especially with a microservice architecture, you need to adopt an “always forward, never back” mentality. Do your best to resolve issues with a code change that progresses your app forward instead of going back in time to an older commit.
对于CI / CD，尤其是在微服务体系结构中，您需要采取“始终向前，永不后退”的思路。 尽最大努力解决代码更改问题，该更改使您的应用前进，而不是及时退回到较早的提交。
Things will go wrong. They always do, and that’s OK. Having a strategy in place before moving to CI/CD will help curb the anxiety of the developers, support, and clients.
事情会出错。 他们总是这样做，没关系。 在转向CI / CD之前制定适当的策略将有助于减少开发人员，支持人员和客户的焦虑。
One of the best things you can do to help catch when things are about to go horribly wrong is to set up proactive monitoring.
当事情将要发生严重错误时，您可以做的最好的事情之一就是设置主动监视。
You want to know there is a problem before your customers do.
您想先于客户知道一个问题。
There are many ways to do proactive monitoring, and it varies greatly depending on your architecture. One effective method that you can use no matter what architecture you have is something like a Postman Monitor.
进行主动监视的方法有很多，根据您的体系结构，其变化很大。 无论您使用哪种架构，都可以使用的一种有效方法是Postman Monitor 。
Monitors run a set of tests throughout the day and alert you if anything goes wrong. You can make them run through security audits, business processes, or validate API contracts. All you need is an API.
监视器全天运行一组测试，并在出现任何问题时提醒您。 您可以使它们通过安全审核，业务流程运行或验证API合同。 您只需要一个API。
明智地分手工作 (Be Smart About How You Break Up the Work)
The CI/CD mantra is small, incremental changes. We all know that not all new app features are small. Maybe you’re implementing a search feature for your application.
CI / CD的口头禅很小， 增量更改。 我们都知道，并非所有新的应用程序功能都很小。 也许您正在为应用程序实现搜索功能。
Adding a search requires a number of changes:
添加搜索需要进行许多更改：
- Setting up Elasticsearch. 设置Elasticsearch。
- Populating Elasticsearch indices. 填充Elasticsearch索引。
- Creating a way to get new data added to the indices. 创建一种将新数据添加到索引的方法。
- Building the search endpoints. 构建搜索端点。
- Providing a way to search in the UI. 提供一种在用户界面中进行搜索的方式。
With a traditional release cycle, you would simply build all these components and ship the final product. But that’s not how it works with CI/CD.
在传统的发布周期中，您只需构建所有这些组件并交付最终产品即可。 但这不是CI / CD的工作方式。
Each bullet point above is going to be a separate push to production. You will incrementally build the feature up over time, and the very last thing you do is provide a way to access it through the UI.
上面的每个要点将单独推动生产。 您将随着时间的推移逐步构建该功能，最后要做的就是提供一种通过UI进行访问的方法。
You can and should build your back-end functionality first so you can assemble automated tests and verify it works as expected. After you know it works, then you can show your users that the new feature exists.
您可以并且应该首先构建您的后端功能，以便您可以组装自动化测试并验证其是否按预期工作。 当你知道它的工作原理， 那么你就可以显示您的用户，新的功能存在。
To your customers, you just released a giant new feature. In actuality, it’s been there for days/weeks/months — just invisible. You’ve built it, tested it, automated it, and regression tested everything. Then you can hand over the keys.
对于您的客户，您刚刚发布了一项巨大的新功能。 实际上，它已经存在了几天/几周/几个月-只是看不见。 您已经构建，测试，自动化并通过回归测试了所有内容。 然后，您可以交出钥匙。
结论 (Conclusion)
As with most things, CI/CD is not as simple as it sounds. If you want to build secure, reliable software, you have to understand the ins and outs of what you’re getting into.
与大多数事情一样，CI / CD并不像听起来那样简单。 如果要构建安全，可靠的软件，则必须了解所学内容的来龙去脉。
Set the expectations that things are changing beforehand. Don’t just rip off the Band-Aid.
事先设定事情会发生变化的期望。 不要只是撕掉创可贴。
Get into the small, incremental change mindset. Feel confident pushing to production multiple times a day.
进入小的，渐进式的变更思维定式。 每天有几次自信地投入生产。
Automate everything. Seriously, automate everything.
自动化一切。 认真地，使一切自动化。
Put contingency plans in place. Have a process to troubleshoot, fix, test, and deploy a high-priority issue in minutes or hours — not days or weeks.
制定应急计划。 具有在几分钟或几小时内(而不是几天或几周)内进行故障排除，修复，测试和部署高优先级问题的过程。
Be smart about how you build. Your app gets better little by little every day. Keep your changes small and focused. Put a development plan in place before you start coding.
明智地建立自己的方式。 您的应用每天都在变得越来越好。 使您的更改小而集中。 开始编码之前，制定适当的开发计划。
CI/CD is absolutely worth it. After you get over the “everything is different” shock, you’ll wonder how you ever did development any other way. Fast turnaround on issues, features developed in the blink of an eye, and a clear view of your system’s health.
CI / CD绝对值得。 克服“一切都不同”的冲击之后，您会想知道您是如何以其他方式进行开发的。 快速解决问题，眨眼间开发的功能以及对系统运行状况的清晰了解。
Good luck!
祝好运！
翻译自: https://medium.com/better-programming/are-you-really-ready-for-ci-cd-9a8bf6d01b8a
ci /cd
763
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
