構建持續交付

by Simon Schwartz

西蒙·施瓦茨(Simon Schwartz)

如何使交付成為您的重點將如何幫助您構建高質量的應用程序 (How making delivery your focus will help you build quality applications)

I was recently asked by our company’s executive team why our team was able to develop improvements to our product so quickly. This blog outlines some key guidelines, from a technical point of view, that our team followed to x iterate our product at speed safely. I tried my darndest to stay high level in this post while still providing technical details. The techniques we talk about aren’t things that we invented.

公司執行團隊最近問我為什么我們的團隊能夠如此Swift地開發出對我們產品的改進。 該博客從技術角度概述了一些關鍵準則，我們的團隊遵循這些準則來安全快速地迭代我們的產品。 我盡我最大的努力使這篇文章保持高水平，同時仍然提供技術細節。 我們談論的技術不是我們發明的東西。

My fellow tech comrades on the team and I saw it as our role to reduce the friction to delivering value to our users. We also aimed to maintain a high quality of the applications we were responsible for. We did a large part of this by removing, simplifying, and automating the processes around delivering updates to our production codebase.

我的團隊中的技術同志，我將其視為減少為用戶提供價值的摩擦的角色。 我們還旨在保持我們負責的應用程序的高質量。 我們通過刪除，簡化和自動化將更新交付到生產代碼庫的過程來完成了大部分工作。

Keep in mind there are some projects that may have inherent complexity. Some of the techniques our team used may not fit your project. From my experience, working with legacy software can make it hard or impossible to simplify certain processes truly.

請記住，有些項目可能具有固有的復雜性。 我們的團隊使用的某些技術可能不適合您的項目。 根據我的經驗，使用舊版軟件可能很難或不可能真正簡化某些流程。

使交付成為重點 (Make delivery the focus)

Our team prioritized delivering frequent improvements to the production codebase above everything else. Well almost — we put things like mental health, letting people take a day off if they were sick, and being nice ahead of delivery.

我們的團隊優先考慮對生產代碼庫進行頻繁的改進，而不是其他所有方面。 好吧，幾乎-我們采取了心理健康之類的措施，讓人們在生病的時候可以放假一天，并在分娩前保持良好狀態。

Code in production is the goal. We made sure that all ideas, designs and feature requests had a clear path for how we were going to get it to production. One technique we used to re-enforce this was only to show working code in showcases. We banned powerpoints and design mockups. We also found this made our showcases more engaging and interesting.

生產中的代碼是目標。 我們確保所有想法，設計和功能要求都有一條明確的路線，說明我們如何將其投入生產。 我們用來加強此功能的一種技術只是在展示柜中顯示工作代碼。 我們禁止使用Powerpoint和設計模型。 我們還發現這使我們的展示柜更具吸引力和趣味性。

Meetings are optional. We found that this encouraged people who called meetings to articulate the purpose and value of the meeting clearly. It was up to team members to decide if they should attend a meeting. We wanted to prevent developers from being unnecessarily interrupted. It can take upwards of 30 minutes for someone to return to a productive state after being interrupted.

會議是可選的。 我們發現，這鼓勵召集會議的人清楚地闡明會議的目的和價值。 由團隊成員決定是否應參加會議。 我們希望防止開發人員受到不必要的干擾。 某人被打擾后可能要花費30分鐘以上的時間才能恢復到生產狀態。

Spend time solving user problems, not technology problems. We wanted to avoid spending countless hours discussing what technology to use or building our own technology. We used AWS Lambda so we didn’t have to think about servers and scaling. We used Create React App so we didn’t have to worry about build configuration for our front end app. We made early tech decisions and stuck to them.

花時間解決用戶問題，而不是技術問題。 我們希望避免花費無數時間討論要使用的技術或構建自己的技術。 我們使用了AWS Lambda，因此我們不必考慮服務器和擴展。 我們使用了Create React App，因此我們不必擔心前端應用程序的構建配置。 我們做出了早期的技術決策并堅持了下來。

？ 我們試圖避免。 (? What we tried to avoid.)

• We avoided spending weeks building our own tooling or frameworks when we could re-use them from elsewhere.
  當我們可以從其他地方重用它們時，我們避免花費數周時間來構建自己的工具或框架。
• We avoided adding unnecessarily complex processes or ceremonies to the team. This included convoluted kanban boards or agile processes that weren’t benefiting us.
  我們避免向團隊添加不必要的復雜流程或儀式。 其中包括混亂的看板或敏捷流程，這些都沒有使我們受益。

• We avoided spending weeks designing, building and supporting features that had no proof they would be useful to our users. Our design team did a great job of designing features based on user feedback and analytics.

  我們避免花費數周的時間來設計，構建和支持功能，而這些功能并沒有證明它們對我們的用戶有用。 我們的設計團隊在基于用戶反饋和分析的功能設計方面做得非常出色。

使部署成為非事件 (Make deployments a non-event)

Having a rapid release cycle meant we could get new features out to our users as soon as they were ready. We also recovered from bugs and outages much quicker. A major challenge of high-frequency deployments is moving at pace without introducing bugs. Automating this process is critical as it vastly reduces the time and effort it takes to deploy updates.

快速的發布周期意味著我們可以在用戶準備就緒后立即向他們推出新功能。 我們還可以更快地從錯誤和中斷中恢復。 高頻部署的主要挑戰是在不引入錯誤的情況下按步伐移動。 自動化此過程至關重要，因為它可以大大減少部署更新所需的時間和精力。

Automate the deployment. Rapid delivery requires the deployment process to be as frictionless as possible. Luckily nowadays we have many tools that can automate the entire deployment process. I recommend tools such as CircleCI and TravisCI. Our setup was when the new code was added to the release branch, the code was automatically deployed by our deployment tool.

自動化部署。 快速交付要求部署過程盡可能無摩擦。 幸運的是，如今，我們有許多工具可以自動化整個部署過程。 我建議使用CircleCI和TravisCI之類的工具。 我們的設置是在將新代碼添加到release分支后，該代碼由我們的部署工具自動部署。

Write (and automate) tests. When deploying code changes automatically, it is critical to understand the impacts the changes will have and to stop deployments that introduce bugs or regressions. This means we needed to write tests that confirm the code is functioning as expected.

編寫(和自動化)測試 。 當自動部署代碼更改時，至關重要的是了解更改將產生的影響并停止部署會引入錯誤或回歸的部署。 這意味著我們需要編寫測試以確認代碼是否按預期運行。

Whenever we integrate new code to a release branch, the CI tool automatically runs our test suite. Any failures in the test suite will cancel the deployment process. Developers would also run this test suite locally to confirm everything worked before pushing changes. Automated testing is also much quicker, less cumbersome and less prone to human error than manual testing.

每當我們將新代碼集成到發布分支時，CI工具都會自動運行我們的測試套件。 測試套件中的任何失敗都將取消部署過程。 開發人員還將在本地運行該測試套件，以在推動更改之前確認一切正常。 與手動測試相比，自動測試還更快，更麻煩并且更不容易出現人為錯誤。

Delivering at speed doesn’t work if all new code needs to be manually tested by a human for an hour. As a team, we agreed that we would write tests for all the code we wrote. For cases where it wasn’t practical to write tests, we would need to give a reason. Any time we fixed a bug, we would also write a test that covered the bug. We made sure that we had tests for common user interactions and journeys (integration tests). As well as tests for the individual functions that made up our applications(unit tests).

如果所有新代碼都需要人工人工測試一個小時，則無法快速交付。 作為一個團隊，我們同意為所有編寫的代碼編寫測試。 對于編寫測試不切實際的情況，我們需要給出一個理由。 每當我們修復錯誤時，我們還將編寫覆蓋該錯誤的測試。 我們確保已針對常見的用戶交互和旅程進行了測試(集成測試)。 以及組成我們應用程序的各個功能的測試(單元測試)。

Small frequent updates. Updating our codebase in small increments increased the rate we delivered improvements to our users. Small updates are easier to integrate into the codebase. Our code review process became more rigorous. It was easier and quicker for developers to review small pull requests. It is much easier to identify issues and impacts of new code because the surface area of the code was so small.

少量頻繁更新。 以較小的增量更新代碼庫可以提高我們為用戶提供的改進速度。 較小的更新更易于集成到代碼庫中。 我們的代碼審查過程變得更加嚴格。 對于開發人員而言，審查小型拉取請求更容易，更快捷。 由于代碼的表面積很小，因此識別新代碼的問題和影響要容易得多。

One technique we found useful was moving the design quality assurance(QA) audit process to the pull request level. This made the QA process more focused and quicker as opposed to when it carried out every few days on a large set of multiple changes. As a team, we made an agreement that we would keep PRs small.

我們發現一種有用的技術是將設計質量保證(QA)審核過程移至拉動請求級別。 與每隔幾天對大量更改進行一次質量檢查相比，這使質量檢查過程更加集中，更快。 作為一個團隊，我們達成了一項協議，我們將使PR保持較小。

We also agreed that we would review PRs within half a day. If we weren’t able to review within that time frame, we needed to let the author know.

我們還同意，我們將在半天之內審查PR。 如果我們無法在該時間范圍內進行審核，則需要告知作者。

？ 我們試圖避免。 (? What we tried to avoid.)

• We avoided manually doing tasks that we could otherwise automate.
  我們避免了手動執行本來可以自動化的任務。
• We avoided risks associated with deploying a large amount of code all at once. It’s not uncommon to deploy code that has bugs that are not picked up or bugs that only surface when the code runs at scale. The larger the surface area of our deployments, the larger the impact these issues will have.
  我們避免了一次全部部署大量代碼帶來的風險。 部署具有未被發現的錯誤或僅在代碼大規模運行時才浮出水面的錯誤的情況并不少見。 我們的部署的表面積越大，這些問題將產生的影響越大。

使更改代碼簡單安全 (Make changing code simple and safe)

“To me, there is only one definition of well designed code. Well designed code is code that is easy to change” — Dave Thomas“對我來說，只有一個定義良好的代碼定義。 設計良好的代碼就是易于更改的代碼” – Dave Thomas

Having the ability to deploy code changes on demand is pointless if changing the code is hard and time-consuming. Writing code that is easy to understand and update helps us iterate at speed. As a technical team, we kept each other accountable through our code review process to ensure we were writing code as clearly and simply as possible.

如果更改代碼既困難又耗時，則能夠按需部署代碼更改就毫無意義。 編寫易于理解和更新的代碼有助于我們快速迭代。 作為技術團隊，我們在代碼審查過程中互相追究責任，以確保我們盡可能清楚，簡單地編寫代碼。

Write modular and reusable code. Functions are the building blocks of our applications. These functions should be small, decoupled and have a single purpose. This makes it easier for developers to follow and understand the logic of the application. It’s easier to repurpose existing functions to reduce the amount of code written. Changing functions is much safer because the surface area of function is so small. The effects of the change are easier to understand. As a team, we would carefully review each others pull requests and give feedback to help each other write the best code we could.

編寫模塊化和可重用的代碼。 功能是我們應用程序的基礎。 這些功能應小巧，分離，并具有單一目的。 這使開發人員更容易遵循和理解應用程序的邏輯。 重新利用現有功能以減少編寫的代碼量更加容易。 更改功能要安全得多，因為功能的表面積很小。 更改的影響更容易理解。 作為一個團隊，我們將仔細檢查彼此的拉取請求并提供反饋，以幫助彼此編寫盡可能好的代碼。

Write code for humans. There are two primary users of the code we write: computers who run the code and humans who read and change the code. Most developers are pretty good at writing code for computers. If your code runs or complies without bugs — it means you did a good job writing code for the computer. Some developers forget about writing code for humans. If the code is hard to understand it will take longer for developers to understand and update the code. We focused on making it clear the purpose, outputs, and inputs of each function.

為人類編寫代碼。 我們編寫代碼的兩個主要用戶：運行代碼的計算機和閱讀和更改代碼的人員。 大多數開發人員都擅長為計算機編寫代碼。 如果您的代碼運行或遵照執行，沒有錯誤-這意味著您在編寫計算機代碼方面做得很好。 一些開發人員忘記了為人類編寫代碼。 如果代碼難以理解，開發人員將需要更長的時間來理解和更新代碼。 我們專注于明確每個功能的目的，輸出和輸入。

The inputs and outputs of functions were made clear with the type system. We used the inbuilt type system when using Go, and Flow when using JavaScript.

類型系統使功能的輸入和輸出變得清晰。 使用Go時使用內置類型系統，使用JavaScript時使用Flow。

We chose descriptive names for our variables. This made it clearer what data the variable held or what function is performed.

我們為變量選擇了描述性名稱。 這樣可以使變量保存哪些數據或執行什么功能變得更加清晰。

// Both these functions do the same thingfunction a(arr) { return arr.filter(it => it.age < 30)}function getUsersUnder30(userList) { return userList.filter(user => user.age < 30)}

Write testable code. Whenever we change the code we need to be sure our changes have not regressed the previous functionality of the code. This is one of the great benefits of having tests. It adds a level of safety to making code changes. We made our lives easier by writing code in a way that made it simple to write tests for. A technique for writing code that is easy to test, is to use pure functions.

編寫可測試的代碼。 每當我們更改代碼時，都需要確保所做的更改未使代碼的先前功能退步。 這是進行測試的巨大好處之一。 它為更改代碼增加了一定的安全性。 通過以簡化編寫測試的方式編寫代碼，使生活變得更輕松。 編寫易于測試的代碼的技術是使用純函數 。

A pure function is a function that given the same inputs, will always return the same outputs. These functions are super simple to test. If you are interested in learning more about pure functions Eric Elliot has a fantastic article describing pure functions.

純函數是給定相同輸入的函數，將始終返回相同的輸出。 這些功能非常易于測試。 如果您有興趣了解有關純函數的更多信息，那么Eric Elliot有一篇很棒的文章描述了純函數 。

Unfortunately, you cannot write a function as a pure function if it has side effects. A side effect is something that operates outside of the scope of its function. This could be operations such as writing a file or sending an API request. Side effects can be tricky to test at the unit level, so these were separated from our pure functions.

不幸的是，如果函數具有副作用 ，則不能將其編寫為純函數。 副作用是超出其功能范圍的事情。 這可能是諸如寫入文件或發送API請求之類的操作。 在單位級別測試副作用可能很棘手，因此將這些副作用與我們的純函數分開了。

？ 我們試圖避免。 (? What we tried to avoid.)

• We avoided wasting time manually testing scenarios that we could automate.
  我們避免了浪費時間手動測試可以自動化的方案。
• We avoided compromising code quality for speed. Compromising code quality for speed is redundant. Not only are you more likely to introduce bugs, but you are also creating a codebase that will eventually be very hard to change and debug. This will significantly slow down your ability to deliver new features and bug fixes.
  我們避免為了速度而犧牲代碼質量。 為了速度而犧牲代碼質量是多余的。 您不僅更有可能引入錯誤，而且還創建了最終將很難更改和調試的代碼庫。 這將大大減慢您交付新功能和錯誤修復的能力。

Thanks for reading!

謝謝閱讀！

翻譯自: https://www.freecodecamp.org/news/making-delivery-the-focus-techniques-for-delivering-quality-applications-222b79d301d9/

構建持續交付

總結

以上是生活随笔為你收集整理的构建持续交付_如何使交付成为您的重点将如何帮助您构建高质量的应用程序的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。