Các doanh nghiệp ngày nay đang chịu áp lực liên tục trong việc phát hành các tính năng và bản cập nhật mới nhanh hơn bao giờ hết. Để đáp ứng những nhu cầu này, nhiều tổ chức đã chuyển sang thực hành DevOps. Ví dụ, tích hợp liên tục (CI) và phân phối liên tục (CD).
Các quy trình CI/CD được thiết kế để rút ngắn và tối ưu hóa vòng phản hồi giữa quá trình phát triển và hoạt động. Chúng đang cho phép các doanh nghiệp lặp lại nhanh chóng các tính năng mới và đưa chúng đến tay người dùng nhanh nhất có thể. Tuy nhiên, các quy trình này thường có thể đưa ra những thách thức riêng, chẳng hạn như thời gian chờ phản hồi lâu hoặc các vấn đề khó theo dõi.
Do đó, trước khi chuyển sang truy vấn chính, trước tiên hãy giải thích các thuật ngữ này để hiểu rõ hơn.
Vòng phản hồi DevOps là gì?
Như tên cho thấy, vòng phản hồi DevOps là chu kỳ phản hồi giữa các nhóm khác nhau tham gia vào quá trình phát triển và vận hành ứng dụng phần mềm. Các vòng phản hồi này nhằm mục đích đảm bảo rằng mọi người đều ở trên cùng một trang. Thêm vào đó, không có tắc nghẽn trong quá trình phát triển.
DevOps là dạng viết tắt của phát triển (Dev) và vận hành CNTT (Ops). Vì vậy, nó là một phương pháp kết hợp cả phát triển và vận hành trong phát triển phần mềm. Cách tiếp cận hiện đại này tập trung vào tốc độ, chất lượng và sự cộng tác. Trong khi ở các mô hình truyền thống, phát triển và vận hành là hai thực thể khác nhau với các mục tiêu khác nhau. Họ làm việc trong các silo riêng biệt. Tuy nhiên, mô hình DevOps tập trung vào việc tích hợp các nhóm vận hành và phát triển trong suốt vòng đời phát triển phần mềm (SDLC).
Ví dụ: một nhà phát triển viết mã và cam kết mã đó vào kho lưu trữ trung tâm. Sau đó, nhóm vận hành lấy mã đó và triển khai nó đến máy chủ sản xuất. Có một vòng phản hồi liên tục giữa hai đội này. Vì vậy, nếu có bất kỳ vấn đề nào trong mã, nhóm vận hành có thể nhanh chóng gửi phản hồi đó cho nhóm phát triển. Và nhà phát triển có thể sửa mã và cam kết lại. Bằng cách này, vòng phản hồi đã tối ưu hóa quy trình bằng cách rút ngắn vòng phản hồi DevOps.
Tuy nhiên, các vòng phản hồi DevOps khá quan trọng vì chúng giúp cải thiện chất lượng phát triển phần mềm. Họ cũng đảm bảo rằng các tính năng được phân phối đúng hạn. Và theo sự mong đợi của khách hàng. Ngoài ra, các vòng phản hồi dài hoặc không có vòng phản hồi nào có thể dẫn đến một số vấn đề. Hơn nữa, nó cũng làm chậm quá trình phát triển và phân phối phần mềm. Điều này càng tác động tiêu cực đến mối quan hệ giữa các hoạt động CNTT và các nhóm phát triển.
Một số vòng phản hồi là gì và chúng hoạt động như thế nào trong tổ chức DevOps?
Có hai vòng phản hồi, vòng phản hồi Khuếch đại và vòng phản hồi Cân bằng. Vòng phản hồi khuếch đại còn được gọi là vòng tăng cường hoặc tăng tốc. Đó là vòng phản hồi tích cực.
Vòng phản hồi cân bằng ngược lại với vòng phản hồi khuếch đại vì nó là vòng phản hồi âm. Hãy xem xét kỹ hơn các vòng phản hồi này và cách chúng hoạt động trong DevOps:
Khuếch đại vòng phản hồi
Vòng phản hồi khuếch đại là vòng phản hồi dương trong đó đầu ra của hệ thống khuếch đại đầu vào. Nói cách khác, hệ thống nhận được nhiều hơn những gì nó đã nhận được. Ví dụ: mã được nhà phát triển cam kết là tốt. Vì vậy, mã được triển khai để sản xuất mà không gặp bất kỳ sự cố nào. Điều này dẫn đến một khách hàng hài lòng, yêu thích các tính năng mới và nói với tất cả bạn bè của họ về sản phẩm mới tuyệt vời này. Kết quả là, công ty có nhiều khách hàng hơn và kinh doanh nhiều hơn.
Khi khuếch đại vòng phản hồi, sự thay đổi diễn ra theo một hướng, dẫn đến sự thay đổi có cường độ lớn hơn. Mục đích của vòng phản hồi này là để tăng tốc quá trình . Đồng thời, vòng phản hồi cân bằng làm chậm hoặc dừng quá trình. Trong một tổ chức DevOps, một vòng phản hồi khuếch đại có thể được tạo giữa các nhóm phát triển và vận hành. Để tiếp tục ví dụ trước, giả sử mã do nhà phát triển cam kết có chất lượng tốt. Vì vậy, nhóm vận hành có thể nhanh chóng đưa ra phản hồi cho nhóm phát triển. Do đó, nhà phát triển có thể sửa mã và cam kết lại.
Cân bằng vòng phản hồi
Ngược lại, vòng phản hồi cân bằng là một vòng phản hồi tiêu cực. Điều này là do đầu ra của hệ thống làm giảm đầu vào. Nói cách khác, hệ thống nhận được ít hơn những gì nó đã nhận được. Ví dụ: mã do nhà phát triển cam kết có lỗi. Vì vậy, mã không được triển khai để sản xuất. Kết quả là, khách hàng không hài lòng vì họ không nhận được các tính năng mới mà họ mong đợi. Vòng phản hồi này còn được gọi là vòng phản hồi tiêu cực vì nó phản đối hoặc làm chậm quá trình. Vòng phản hồi này nhằm mục đích đưa hệ thống trở lại trạng thái cân bằng.
Vòng phản hồi cân bằng hoạt động giữa các nhóm phát triển và vận hành trong một tổ chức DevOps. Ví dụ: giả sử mã do nhà phát triển cam kết có lỗi khi mã này được gửi đến nhóm vận hành. Họ nhanh chóng đưa ra phản hồi cho nhóm phát triển bằng cách nêu bật các lỗi và vấn đề. Họ gửi mã lại cho nhà phát triển. Do đó, nhà phát triển có thể sửa mã và cam kết lại. Bằng cách này, vòng phản hồi cố gắng đảm bảo mã chất lượng tốt trong khi tối ưu hóa vòng phản hồi DevOps.
Cả hai vòng phản hồi này đều bắt buộc trong một tổ chức DevOps. Chúng giúp tăng tốc quá trình phát triển và phân phối phần mềm. Cũng như nâng cao mối quan hệ giữa các hoạt động CNTT và các nhóm phát triển. Để tối ưu hóa các vòng phản hồi DevOps, điều quan trọng là phải sử dụng cả hai vòng phản hồi này. Chúng nên được sử dụng cùng nhau để rút ngắn vòng phản hồi và cải thiện chất lượng của mã.
Sự khác biệt giữa hệ thống thông báo và vòng phản hồi
Một sự hiểu lầm phổ biến ở những người mới sử dụng DevOps là không thể phân biệt giữa hệ thống thông báo và vòng phản hồi. Họ coi hệ thống thông báo và vòng phản hồi là một và giống nhau. Tuy nhiên, chúng đều quan trọng và phục vụ các mục đích khác nhau trong DevOps. Do đó, một hệ thống thông báo là một cách để nhận thông tin về các sự kiện đã xảy ra. Ví dụ: bạn có thể nhận được thông báo khi bản dựng không thành công hoặc chạy thử nghiệm. Một số loại hệ thống thông báo phổ biến là email, Slack và HipChat.
Ngược lại, vòng lặp phản hồi là về việc nhận phản hồi về các sự kiện. Ví dụ: bạn có thể nhận được phản hồi về kết quả kiểm tra hoặc trạng thái bản dựng. Các vòng phản hồi rất quan trọng vì chúng giúp bạn hiểu điều gì đang xảy ra trong hệ thống của mình. Và họ cũng giúp bạn xác định vấn đề sớm. Các loại vòng phản hồi phổ biến trong DevOps là ghi nhật ký, giám sát và cảnh báo. Vì vậy, bắt buộc phải có cả hệ thống thông báo và vòng phản hồi. Nhưng đừng hiểu lầm sự khác biệt giữa hai điều này.
Tích hợp liên tục (CI) và phân phối liên tục (CD) là gì
Thông thường, mọi người sử dụng thuật ngữ CI và CD thay thế cho nhau. Tuy nhiên, chúng là hai khái niệm khác nhau. Cả CI và CD đều đóng vai trò quan trọng trong DevOps nhưng có các mục đích khác nhau.
Tích hợp liên tục (CI)
Phương pháp phân phối phần mềm này hợp nhất các bản sao làm việc của nhà phát triển thành một đường dây chính được chia sẻ. Mục đích của CI là để tránh địa ngục tích hợp. Điều đó có thể xảy ra khi nhiều nhà phát triển đang làm việc trên cùng một cơ sở mã. Hơn nữa, nó cũng giúp phát hiện lỗi sớm và tránh những bất ngờ vào phút cuối khi phát hành các tính năng hoặc sản phẩm mới. Tích hợp thường xuyên giúp bạn phát hiện lỗi nhanh chóng và định vị chúng dễ dàng hơn. Nó nên được tích hợp vào thử nghiệm và xây dựng đơn vị tự động. Vì vậy, mỗi khi mã được cam kết với dòng chính, nó sẽ tự động kích hoạt bản dựng. Và chạy một bộ kiểm tra để xác minh tính chính xác của mã.
Phát liên tục (CD)
CD là cách tiếp cận để tự động hóa và giám sát quá trình phân phối phần mềm. Để phần mềm được phát hành cho người dùng/khách hàng một cách nhanh chóng và đáng tin cậy nhất có thể. Đó là một quy trình liên tục bắt đầu bằng một cam kết trong hệ thống kiểm soát phiên bản. Và kết thúc với việc phần mềm được triển khai trong sản xuất. Mục đích chính của CD là đảm bảo rằng phần mềm luôn ở trạng thái có thể triển khai. Vì vậy, nó có thể được phát hành để sản xuất bất cứ lúc nào.
Tuy nhiên, CD yêu cầu mức độ tự động hóa cao để triển khai phần mềm thường xuyên và đáng tin cậy. Do đó, quy trình phân phối phần mềm bao gồm tự động hóa việc xây dựng, thử nghiệm và triển khai mã. Ngoài ra, đường dẫn CD thường được sử dụng cùng với CI. Do đó, mỗi khi mã được cam kết, mã sẽ tự động đi qua quy trình và được triển khai vào sản xuất nếu vượt qua tất cả các bài kiểm tra.
Làm cách nào để tối ưu hóa các vòng phản hồi DevOps?
Việc tối ưu hóa các vòng phản hồi DevOps rất quan trọng vì một số lý do. Như đã đề cập trước đó, nó giúp cải thiện chất lượng phát triển và phân phối phần mềm. Nó cũng đảm bảo rằng các tính năng được phân phối đúng thời hạn và theo mong đợi của khách hàng. Có nhiều cách để tối ưu hóa vòng phản hồi trong DevOps. Một số trong số họ được đề cập dưới đây:
Chọn loại vòng lặp phản hồi có liên quan
Bước đầu tiên là chọn loại vòng phản hồi có liên quan. Bạn có thể chọn từ hai vòng phản hồi trong DevOps - khuếch đại và cân bằng. Các vòng phản hồi khuếch đại là những vòng củng cố trạng thái hiện tại. Mặt khác, các vòng cân bằng là những vòng giúp duy trì trạng thái cân bằng. Bạn cần hiểu loại vòng lặp phản hồi sẽ hiệu quả nhất cho nhóm của mình. Và sau đó thực hiện nó cho phù hợp.
Khám phá các vòng phản hồi hiện có
Bước tiếp theo là khám phá các vòng phản hồi hiện có trong tổ chức của bạn. Có thể có một số vòng phản hồi đã có nhưng thực tế không được sử dụng. Điều quan trọng là xác định các vòng phản hồi này và xác định cách chúng có thể được sử dụng hiệu quả hơn.
Tránh nợ kỹ thuật
Nợ kỹ thuật phải tránh để tăng cường tối ưu hóa các vòng phản hồi. Nợ kỹ thuật là nhóm quyết định đưa ra để phân phối nhanh chóng thay vì tối ưu hóa mã. Để tránh điều này, điều quan trọng là phải hiểu rõ ràng về những đánh đổi có liên quan. Hành động ngay lập tức trên các thông báo và cảnh báo để khắc phục mọi sự cố và tồn đọng có thể phát sinh. Sau đó, tự động hóa quy trình để bạn có thể tập trung vào các nhiệm vụ quan trọng hơn.
Lấy thông tin phản hồi từ các nguồn của con người
Ngoài việc thu thập phản hồi từ các nguồn tự động, điều quan trọng là lấy phản hồi từ các nguồn của con người. Điều này sẽ giúp bạn có ý tưởng về trải nghiệm người dùng . Và cách phần mềm đang được sử dụng trong thế giới thực. Hỏi nhóm DevOps và chính bạn để nhận phản hồi. Ngoài ra, lấy phản hồi từ khách hàng và các bên liên quan khác. Điều này sẽ giúp bạn hiểu các khía cạnh khác nhau của quy trình phát triển phần mềm.
Xác định các vấn đề cụ thể
Việc xác định các vấn đề cụ thể là rất quan trọng để tối ưu hóa các vòng phản hồi. Điều đầu tiên là làm rõ vấn đề mà bạn đang cố gắng giải quyết. Sau đó, khi bạn đã xác định được vấn đề hôm nay, bạn cần theo dõi nó theo thời gian để tự cứu mình khỏi những vấn đề trong tương lai.
Tự động hóa vòng phản hồi
Tự động hóa vòng phản hồi rất quan trọng vì một số lý do. Đầu tiên, nó giúp nâng cao hiệu quả của quá trình. Ngoài ra, nó nâng cao chất lượng phản hồi mà bạn nhận được. Bạn có thể tự động hóa vòng phản hồi bằng cách sử dụng các công cụ khác nhau. Một số công cụ phổ biến là Jenkins, Travis CI và CircleCI. Những công cụ này giúp tự động hóa quá trình phát triển phần mềm.
Huấn luyện đội ngũ
Điều quan trọng là đào tạo nhóm sử dụng vòng phản hồi một cách hiệu quả. Nhóm nên nhận thức được các bước khác nhau liên quan đến quy trình. Hơn nữa, họ phải được đào tạo đủ để đưa ra phản hồi hữu ích và đáng tin cậy. Tuy nhiên, thực hiện một vòng phản hồi là không đủ. Bạn cần chắc chắn rằng nó đang được sử dụng một cách hiệu quả. Cùng với điều này, phản hồi phải có tính khả thi. Nếu không, nó sẽ không được sử dụng.
Khuyến khích hợp tác
Khuyến khích cộng tác là điều quan trọng để tối ưu hóa các vòng phản hồi. Sai lầm phổ biến nhất mà các doanh nghiệp mắc phải là họ khuyến khích các silo. Điều này dẫn đến mất thông tin và có thể tạo ra vấn đề. Thay vào đó, các doanh nghiệp nên khuyến khích sự hợp tác giữa các nhóm khác nhau. Điều này sẽ giúp cải thiện chất lượng vòng phản hồi. Bên cạnh đó, nó cũng sẽ giúp giảm thời gian nhận phản hồi.
Sử dụng đúng công cụ
Có một số công cụ có sẵn cho các vòng phản hồi DevOps. Nhưng không phải tất cả chúng đều phù hợp với tổ chức của bạn. Bạn cần sử dụng đúng công cụ phù hợp với yêu cầu tổ chức của mình. Một số công cụ phổ biến là Jira, Slack và HipChat. Những công cụ này giúp nâng cao hiệu quả của vòng phản hồi.
Tối ưu hóa các vòng phản hồi DevOps trong Tích hợp và phân phối liên tục
Tích hợp liên tục (CI) và phân phối liên tục (CD) tối ưu hóa đáng kể vòng phản hồi DevOps. CI/CD giúp rút ngắn vòng phản hồi bằng cách tự động hóa quy trình phát triển phần mềm. Các thay đổi mã thường xuyên được tích hợp vào nhánh chính trong quá trình tích hợp liên tục. Điều này giúp tránh các vấn đề tích hợp có thể phát sinh do sự chậm trễ trong việc thay đổi mã. Mặt khác, phân phối liên tục giúp cung cấp các thay đổi phần mềm cho người dùng thường xuyên. Nó hỗ trợ nhận phản hồi về những thay đổi từ người dùng một cách nhanh chóng.
Cả tích hợp liên tục và phân phối liên tục đều đóng vai trò quan trọng trong việc nâng cao chất lượng phản hồi. Họ cũng hỗ trợ tiết kiệm thời gian bằng cách tự động hóa quy trình. Những cách tiếp cận này phù hợp nhất để phát triển phần mềm vi dịch vụ vì nó hỗ trợ phân phối nhanh chóng các dự án và ứng dụng phức tạp. Tuy nhiên, việc giảm thiểu sự thiếu hiệu quả và tối đa hóa hiệu quả của đường ống chỉ có thể đạt được khi có vòng phản hồi phù hợp. Đó là lý do tại sao việc lựa chọn công nghệ vòng lặp phản hồi phù hợp là điều cần thiết để thành công. Trong bối cảnh này, các công cụ đường dẫn CD và CI có thể đi một chặng đường dài trong việc tối ưu hóa vòng phản hồi DevOps. Tuy nhiên, nếu bạn muốn cải thiện hơn nữa quy trình, bạn cần tập trung vào các khía cạnh khác. Chúng bao gồm những thứ như tự động hóa thử nghiệm, giám sát và ghi nhật ký.
Tuy nhiên, các công cụ không giới hạn có sẵn trên thị trường và không phải công cụ nào cũng phù hợp với yêu cầu của bạn. Do đó, bạn phải chọn các công cụ dựa trên nhu cầu của dự án. Ví dụ: bạn có thể sử dụng Dịch vụ Azure DevOps để quản lý quy trình phát triển phần mềm của mình nếu bạn đang sử dụng Azure. Các lựa chọn thay thế khác có thể là Jenkins, CloudBees CI, Google cloud build, Circle CI, v.v.
Bạn có thể sử dụng bất kỳ công cụ nào trong số này để tối ưu hóa vòng phản hồi trong quy trình CI/CD của mình. Nhưng hãy đảm bảo chọn cái phù hợp nhất với yêu cầu dự án của bạn. Việc thiết lập một kênh liên lạc giữa nhóm phát triển và nhóm vận hành cũng là điều bắt buộc. Điều này sẽ có lợi cho bạn bằng cách đảm bảo thông tin phản hồi được chuyển một cách chính xác và hiệu quả.
Do đó, bạn không thể thiết lập vòng phản hồi hiệu quả nếu không hiểu quy trình và quy trình làm việc. Ngoài ra, hãy đảm bảo rằng phản hồi được chuyển đến đúng người để họ có thể thực hiện các hành động thích hợp. Cuối cùng, đừng quên theo dõi vòng phản hồi để xem liệu nó có hoạt động như mong muốn hay không. Làm như vậy sẽ cho phép bạn tối ưu hóa vòng phản hồi và tận dụng tối đa nó.
Một số nguyên tắc chính của Tích hợp và phân phối liên tục
Dựa trên nghiên cứu sâu rộng, chúng tôi đã biên soạn một danh sách các nguyên tắc chính sẽ giúp bạn tối ưu hóa vòng phản hồi của mình.
triển khai tự động
Mục đích chính của tích hợp liên tục là để đảm bảo rằng các thay đổi mã được tích hợp thường xuyên vào nhánh chính. Điều này giúp tránh các vấn đề tích hợp có thể phát sinh do sự chậm trễ trong việc thay đổi mã.
Để đạt được điều này, cần phải tự động hóa quá trình tích hợp và phân phối mã. Điều này sẽ giúp tiết kiệm rất nhiều năng lượng và thời gian. Ngoài ra, nó cũng sẽ giúp tránh lỗi của con người.
Vòng phản hồi ngắn
Điều cần thiết là phải có các vòng phản hồi ngắn để nhận phản hồi nhanh về các thay đổi. Điều này sẽ giúp xác định các vấn đề ở giai đoạn đầu và khắc phục chúng cho phù hợp. Bên cạnh đó, nó cải thiện chất lượng phản hồi. Các vòng phản hồi ngắn sẽ giúp bạn tiết kiệm rất nhiều thời gian và công sức trong thời gian dài.
đường ống thử nghiệm
Một nguyên tắc quan trọng khác của tối ưu hóa vòng phản hồi là có một quy trình thử nghiệm. Điều này sẽ giúp kiểm tra các thay đổi mã trước khi chúng được triển khai vào môi trường sản xuất. Chỉ có một cách để đạt được điều này, đó là triển khai và kiểm tra mã.
Thử nghiệm và xây dựng tức thì
Các thay đổi mã mới phải được kiểm tra và xây dựng ngay lập tức sau khi chúng được cam kết. Điều này giúp tránh các vấn đề tích hợp có thể phát sinh do sự chậm trễ trong việc thay đổi mã.
Tính nhất quán của phản hồi
Theo nguyên tắc này, kết quả của quy trình CI phải nhất quán. Điều này chỉ có thể đạt được nếu các thay đổi mã được kiểm tra và xây dựng một cách thường xuyên.
Môi trường giao hàng bất khả tri
Việc cung cấp các thay đổi mã không nên phụ thuộc vào môi trường. Điều này chỉ có thể đạt được nếu mã được triển khai trong một môi trường riêng biệt. Mục đích của việc này là để duy trì tính di động tối đa. Có thể có nhiều nguyên tắc khác để giúp bạn tối ưu hóa vòng phản hồi của mình. Nhưng đây là những điều quan trọng nhất. Vì vậy, hãy ghi nhớ chúng trong khi thiết lập vòng phản hồi của bạn.
kết thúc
Viết mã có thể thú vị và hồi hộp, nhưng đồng thời cũng có một chút thách thức. Để tránh những thách thức, bạn phải thiết lập một vòng phản hồi hiệu quả. Điều này giúp nhận được phản hồi nhanh chóng và ngăn ngừa các sự cố tích hợp có thể phát sinh do sự chậm trễ trong việc thay đổi mã. Để vận hành trơn tru vòng phản hồi của bạn, cần phải hiểu rõ về quy trình làm việc và tự động hóa quy trình. Để tránh tình trạng mã hóa lộn xộn, bạn có thể sử dụng AppMaster, một nền tảng không cần mã giúp công việc của bạn dễ dàng và nhanh hơn. Với sự trợ giúp của AppMaster, bạn có thể tạo các ứng dụng web và di động cùng với phần phụ trợ mạnh mẽ. Nó có một số tính năng có thể giúp bạn tối ưu hóa vòng phản hồi của mình.
câu hỏi thường gặp
Lợi ích chính của CI/CD là gì?
Tính minh bạch, cộng tác, vòng phản hồi ngắn hơn và quy trình tự động là những lợi ích chính của CI/CD. Hơn nữa, nó tránh được lỗi của con người, tiết kiệm thời gian và công sức, đồng thời nâng cao chất lượng phản hồi.
Sự khác biệt chính giữa CI và CD là gì?
Điểm khác biệt chính giữa CI và CD là CI nói về những thay đổi mã, trong khi CD nói về việc triển khai mã. Tuy nhiên, cả CI và CD đều cần thiết cho một vòng phản hồi hiệu quả. Họ làm việc cùng nhau để đạt được mục tiêu chung là phản hồi nhanh hơn và chất lượng được cải thiện.
Các vòng phản hồi quan trọng như thế nào?
Các vòng phản hồi đóng một vai trò quan trọng trong quá trình CI/CD hoạt động trôi chảy. Chúng giúp nhận được phản hồi nhanh chóng và tránh các sự cố tích hợp có thể phát sinh do sự chậm trễ trong việc thay đổi mã.
Điều gì hoạt động tốt ngay cả khi không có tự động hóa?
Nguyên tắc vòng lặp phản hồi về "kiểm tra sớm và thường xuyên" và "quy trình xem xét mã " vẫn hoạt động ngay cả khi không có tự động hóa. Tuy nhiên, nó không hiệu quả bằng tự động hóa. Nó có thể là tốt nhất cho mã chất lượng trong khi xử lý vòng phản hồi khuếch đại hoặc củng cố.
Các nhiệm vụ bị kẹt trong hồ sơ tồn đọng có thể dẫn đến sự cố không?
Có, các nhiệm vụ bị kẹt trong hồ sơ tồn đọng có thể dẫn đến sự cố. Khi các thay đổi mã không được triển khai thường xuyên, nó có thể dẫn đến các sự cố tích hợp.
