Tổng quan về Quy trình và Thủ tục Phát triển

Tài liệu này sẽ cung cấp tổng quan về các Quy trình và Thủ tục Phát triển của Leading2Lean. Quy trình này mô tả các trách nhiệm, chính sách và thủ tục mà Leading2Lean phải tuân theo khi thực hiện các thay đổi đối với dịch vụ sản xuất và hạ tầng. Tất cả nhân viên được yêu cầu tuân thủ chính sách này.

Đội ngũ Công nghệ Leading2Lean được giao nhiệm vụ cung cấp hạ tầng CNTT ổn định và đáng tin cậy cho khách hàng của chúng tôi. Mục đích của Quy trình Phát triển là giảm thiểu gián đoạn dịch vụ đối với môi trường trung tâm dữ liệu và thúc đẩy tính khả dụng cũng như tính toàn vẹn của hệ thống. Giám đốc Kỹ thuật (CTO) chịu trách nhiệm duy trì và cập nhật Quy trình và Thủ tục Phát triển khi cần thiết. Quy trình này còn được điều chỉnh bởi các biện pháp kiểm soát tổ chức được xác định trong chương trình tuân thủ AICPA SOC 2 Type 2 của chúng tôi. Các biện pháp kiểm soát này được kiểm toán bởi kiểm toán viên bên ngoài hàng năm.

Quy trình phát triển bắt đầu khi một nhà phát triển xem xét phiếu yêu cầu, phối hợp với các đồng nghiệp về kiến trúc và thiết kế, viết mã, tiếp nhận phản hồi từ đội ngũ QA và cuối cùng phát hành phần mềm cho khách hàng. 

Phạm vi

Tài liệu này định nghĩa vòng đời của các yêu cầu tính năng và lỗi. Tài liệu cũng mô tả các quy trình và thủ tục được sử dụng để đảm bảo việc kiểm thử và xác thực phù hợp được thực hiện cho mỗi lần phát hành. Tài liệu này không mô tả Quy trình Quản lý Thay đổi như được định nghĩa trong Tổng quan về Chính sách Kiểm soát Thay đổi của chúng tôi.

Định nghĩa

Công việc tồn đọng: Tập hợp các lỗi và tính năng chưa bắt đầu phát triển. Công việc tồn đọng là nơi chứa tất cả các phiếu yêu cầu có mức độ ưu tiên thấp hơn. 

Lỗi: Một tính năng không hoạt động theo đúng dự định. Lỗi có thể có mức độ từ không nghiêm trọng đến cực kỳ nghiêm trọng. Danh sách Lỗi là nơi chứa tất cả các lỗi có mức độ ưu tiên thấp hơn. Phiếu yêu cầu được đưa vào danh sách Lỗi trong cuộc họp Phân loại. Phiếu yêu cầu được giao cho các thành viên đội ngũ phát triển từ danh sách Lỗi.

Tính năng hoặc Cải tiến: Hành vi chưa được phát triển cho phần mềm. Đây có thể là sự sửa đổi chức năng hiện có hoặc tạo ra chức năng mới.

Dự án hoặc Epic: Tập hợp các Lỗi và Tính năng. Các dự án được quản lý trên Lộ trình. 

Lộ trình: Tập hợp các Dự án. Lộ trình là bảng lập kế hoạch cho các dự án lớn hơn. Lộ trình thúc đẩy việc phát triển các tính năng mới, lớn và nhỏ. 

Phân loại: Tập hợp các ticket mới. Danh sách Phân loại là nơi tất cả ticket mới được tạo. Nhóm Phân loại sau đó sẽ chuyển ticket vào danh sách Lỗi, Lộ trình hoặc Tồn đọng.

Tổng quan

Có 3 giai đoạn chính đối với mỗi ticket phát triển: 1. Lập kế hoạch, 2. Phát triển và 3. Kiểm thử đảm bảo Chất lượng. Mỗi giai đoạn sẽ được thảo luận dưới đây.

Lập kế hoạch

Chúng tôi áp dụng phương pháp phân loại đa ngành cho quy trình lập kế hoạch. Các nhóm Hỗ trợ, Phát triển và Chất lượng của chúng tôi thường xuyên họp trong Cuộc họp Phân loại để đánh giá các vấn đề mới, yêu cầu tính năng và cải tiến. Dựa trên mức độ nghiêm trọng, những vấn đề này có thể kích hoạt chu kỳ phản hồi khắc phục sự cố được nâng cấp để khôi phục dịch vụ trong trường hợp có các hạng mục ưu tiên cao hoặc thể hiện sự suy giảm dịch vụ. Nếu không, chúng sẽ được gán mức ưu tiên ban đầu và chuyển cho Nhóm Sản phẩm để lập kế hoạch, sắp xếp thứ tự ưu tiên và lên lịch bổ sung.

Các tính năng thường được lập kế hoạch với sự tham gia của một số ít người.  Những người này có thể bao gồm các thành viên của Nhóm Sản phẩm, chuyên gia về chủ đề, khách hàng, v.v. Quy trình này do nhóm quản lý sản phẩm của chúng tôi thực hiện.

Phần lớn các yêu cầu tính năng sẽ được thảo luận trong cuộc họp Lập kế hoạch Lộ trình. Trong cuộc họp này, các dự án và yêu cầu tính năng được nâng cấp sẽ được thảo luận. Các dự án sẽ được sắp xếp thứ tự ưu tiên so với các dự án khác, còn các yêu cầu tính năng sẽ được xem xét và chuyển vào danh sách tồn đọng. Các yêu cầu tính năng có thể được liên kết với một dự án trên lộ trình.

Phát triển

Sau khi hoàn tất quy trình lập kế hoạch, công việc này được giao cho nhóm Phát triển. Nhóm Phát triển có một tập hợp các môi trường phát triển riêng, phản chiếu môi trường Sản xuất của chúng tôi. Đây là một phần thiết yếu trong chương trình Chất lượng của chúng tôi. Ở mỗi bước trong vòng đời phát triển (Dev, QA, Staging và Sản xuất), chúng tôi duy trì hạ tầng riêng biệt để đảm bảo mọi công việc hoàn thành đều được kiểm thử và xác minh đầy đủ trước khi đưa vào môi trường Sản xuất.

Chúng tôi sử dụng một bộ đầy đủ các công cụ phát triển tiêu chuẩn ngành được thiết kế để kiểm soát phiên bản, kiểm thử tự động, phân tích mã tĩnh và đảm bảo mã nguồn sạch. Những công cụ này cung cấp phản hồi sớm và thường xuyên cho lập trình viên nhằm đảm bảo chất lượng mã tốt nhất có thể. Chúng cũng giúp duy trì sự phân tách phù hợp giữa các nhánh phát triển để tránh việc lẫn lộn giữa các lập trình viên làm việc trên những dự án, nhiệm vụ và thành phần khác nhau của cơ sở mã. Những công cụ này cung cấp một phương thức tiêu chuẩn hóa để đánh giá mã đồng cấp và quy trình phê duyệt, nhằm đảm bảo mọi mã sẵn sàng cho Kiểm thử Đảm bảo Chất lượng đều đã vượt qua tất cả các bước kiểm thử và xác thực tự động.

Các lập trình viên của chúng tôi trao đổi trực tiếp với nhóm hỗ trợ, nhóm sản phẩm hoặc các lập trình viên khác khi phát sinh câu hỏi về cách triển khai một yêu cầu. Mọi thay đổi về giao diện người dùng đều cần được nhóm sản phẩm phê duyệt. Vì các thay đổi về giao diện người dùng ảnh hưởng đến khách hàng và có thể yêu cầu đào tạo, chúng tôi làm việc với khách hàng, nhóm hỗ trợ và nhóm sản phẩm để đảm bảo việc thiết kế mọi thay đổi về giao diện người dùng được thực hiện cẩn trọng nhằm giảm thiểu tác động đến khách hàng. Tất cả các thay đổi về giao diện người dùng cũng được nhóm hỗ trợ xem xét trong giai đoạn Kiểm thử Đảm bảo Chất lượng để xác minh chức năng phù hợp và đảm bảo khách hàng nhận được các Thông báo và chương trình đào tạo phù hợp.

Các lập trình viên được yêu cầu chạy thành công bộ kiểm thử tự động của chúng tôi đối với mọi thay đổi như một phần trong quy trình vận hành thông thường. Khi yêu cầu vượt qua các bài kiểm thử tự động này, yêu cầu đó sẵn sàng được một người khác ngoài lập trình viên xem xét. Sự kiện này cho phép các thành viên chủ chốt trong nhóm biết rằng đã đến lúc đưa ra phản hồi, đồng thời cho thấy yêu cầu đang tiến gần hơn đến việc phát hành.

Tất cả mã đều được một lập trình viên khác đánh giá trước khi chuyển cho nhóm QA. Điều này giúp đảm bảo có hơn một người biết và hiểu những gì đang được thay đổi cũng như lý do thay đổi. Mục đích của việc đánh giá mã là xem xét mục tiêu tổng thể của các thay đổi, kiểm tra mã để phát hiện các lỗi đơn giản, rà soát mã để tìm sự kém hiệu quả, yêu cầu làm rõ khi có điều gì đó chưa phù hợp và cố gắng duy trì tính nhất quán với các tiêu chuẩn cũng như phương pháp tốt nhất trong lập trình. Đôi khi lập trình viên ban đầu sẽ tái cấu trúc mã do phản hồi trong giai đoạn kiểm thử. Nếu điều này dẫn đến một lượng thay đổi mã đáng kể, một lần đánh giá bổ sung sẽ được thực hiện. Khi sự đồng thuận trong việc đánh giá mã được ghi nhận và lập tài liệu, mã đã sẵn sàng được phát hành cho nhóm QA

Kiểm thử Đảm bảo Chất lượng

Sau khi bộ kiểm thử tự động hoàn tất thành công mà không có lỗi và quá trình đánh giá mã đã hoàn tất thành công, nhóm QA có thể bắt đầu quy trình Kiểm thử Đảm bảo Chất lượng.

Hai hoạt động chính trong quy trình kiểm thử là chạy các tập lệnh kiểm thử tự động và kiểm thử thủ công. L2L có một bộ các trường hợp kiểm thử UI và unit được chạy từ dòng lệnh. Ngoài ra còn có một quy trình lint chạy trên mã để kiểm tra các lỗi mã hóa cơ bản. Tất cả các nhà phát triển nên chạy cả bộ kiểm thử và quy trình lint trước khi gửi mã để xem xét. Đội ngũ QA sẽ tự mình xem xét kết quả của bộ kiểm thử tự động sau khi triển khai mã vào môi trường kiểm thử QA. Điều này đảm bảo chúng ta có một môi trường kiểm thử sạch để đánh giá khả năng hoạt động của bản cập nhật mã theo đúng thiết kế và tiêu chuẩn chất lượng của chúng ta.

Đội ngũ QA sẽ điều phối việc kiểm thử mã thủ công để đảm bảo chất lượng bổ sung. Phản hồi từ đội ngũ QA sẽ được đưa vào phiếu phát triển. Thông thường, mã sẽ cần được tái cấu trúc và cập nhật trước khi QA phê duyệt. QA sẽ cho biết mã đã sẵn sàng được hợp nhất bằng cách phê duyệt yêu cầu kéo. QA sẽ hợp nhất mã vào cơ sở mã chính sau khi mọi thứ đã được phê duyệt. Điều này đảm bảo các nhà phát triển không thể hợp nhất mã vào cơ sở mã chính và bỏ qua quy trình QA.

Trong giai đoạn Kiểm thử Đảm bảo Chất lượng, đội ngũ QA cũng sẽ sử dụng các thành viên của đội hỗ trợ và khách hàng để thực hiện kiểm thử chấp nhận người dùng. Những kiểm thử này rất quan trọng để đảm bảo các thay đổi mã có thể sử dụng được, phù hợp với nhu cầu của khách hàng và tuân thủ mọi quy định cũng như yêu cầu của ngành.

Quy trình Kiểm soát Thay đổi và Triển khai vào Môi trường Sản xuất

Để đảm bảo mọi thay đổi đối với môi trường sản xuất của chúng ta tuân theo một quy trình tiêu chuẩn, chúng tôi đã triển khai Quy trình Quản lý Thay đổi như được định nghĩa trong Tổng quan Chính sách Kiểm soát Thay đổi. Điều này đảm bảo chúng ta có các cơ chế kiểm tra và cân bằng phù hợp trong tổ chức để đảm bảo chất lượng, bảo mật và tính khả dụng của môi trường sản xuất. Để biết thêm thông tin về quy trình này, hãy xem liên kết ở trên.

Điều quan trọng cần lưu ý là trong khuôn khổ quy trình kiểm soát thay đổi, L2L sử dụng một tập lệnh triển khai tự động để phát hành phần mềm từ kho mã đến các máy chủ của khách hàng. Nhân viên không trực tiếp cập nhật môi trường sản xuất tại bất kỳ thời điểm nào. Hệ thống tự động này tạo ra dấu vết kiểm tra cho mỗi bản phát hành/triển khai mới và xác minh các phê duyệt phù hợp đã được thực hiện. Sau khi hoàn tất, các tập lệnh phát hành sẽ được phép cập nhật máy chủ sản xuất. Tập lệnh tự động này cũng cung cấp thông báo nội bộ của công ty về các lần triển khai. Sau khi triển khai hoàn tất, hệ thống tự động này cũng thực hiện các "kiểm thử khói" để xác nhận việc triển khai đã thành công và môi trường sản xuất đang hoạt động đúng cách.

Cuộc họp Đánh giá lại

Trong trường hợp mã đã phát hành làm tái xuất hiện một vấn đề cũ hoặc khiến hệ thống cảnh báo, một cuộc họp đánh giá, còn gọi là post-mortem, sẽ được tổ chức. Mục đích của cuộc họp là thu thập các thông tin liên quan đến việc phát hành mã lỗi, thảo luận các cách ngăn chặn những sự việc tương tự xảy ra trong tương lai, phân công nhiệm vụ liên quan đến việc phòng ngừa các sự việc trong tương lai và đào tạo đội ngũ về sự cố. Các cuộc họp này nên diễn ra trong vòng 36 giờ kể từ khi sự việc xảy ra và nên có sự tham gia của càng nhiều lập trình viên và thành viên đội ngũ đảm bảo chất lượng càng tốt để phục vụ việc phân tích nguyên nhân gốc rễ và đào tạo. 

Thông báo cho khách hàng

Thông báo cho khách hàng có thể được thực hiện nhiều lần trong suốt quy trình này. Khách hàng thường được tham vấn trong các giai đoạn lập kế hoạch, phát triển, QA cũng như sau khi mã được phát hành. Khách hàng sẽ được thông báo bằng các phương thức sau:

• Liên hệ trực tiếp / Các cuộc họp đã lên lịch. Khách hàng tham gia vào các dự án phát triển cụ thể có thể được mời tham dự các cuộc họp cập nhật định kỳ để xem xét kế hoạch, thiết kế và tình trạng dự án.
• Email cá nhân gửi khách hàng. Tất cả các phiếu hỗ trợ ban đầu sẽ được cập nhật để thông báo cho khách hàng rằng thay đổi đã được phát hành lên các máy chủ Sản xuất và phiếu sẽ được đóng. Nếu chưa có phiếu hỗ trợ nào được tạo, nhân viên hỗ trợ có thể liên hệ trực tiếp với khách hàng. Nếu chỉ một khách hàng bị ảnh hưởng bởi thay đổi, các hình thức thông báo khác có thể không được sử dụng.
• Nhật ký thay đổi. Tất cả các thay đổi ảnh hưởng đến khách hàng sẽ có nhật ký thay đổi. Nội dung này bao gồm các bản sửa lỗi, cập nhật nhỏ và yêu cầu tính năng. Khi một thay đổi chỉ ảnh hưởng đến một khách hàng, tác động là nhỏ và khách hàng đã được liên hệ trực tiếp, nhật ký thay đổi có thể không được thêm vào. Khách hàng có thể truy cập nhật ký thay đổi từ menu Hỗ trợ trong Ứng dụng.
• Email hàng loạt. Email sẽ được gửi đến tất cả Quản trị viên đối với mọi thay đổi lớn của ứng dụng. Email hàng loạt chủ yếu được sử dụng cho các thông báo sản phẩm và cải tiến giao diện người dùng lớn, nhưng cũng có thể được sử dụng cho các trường hợp khác.
• Thông báo trong ứng dụng có thể được sử dụng cho các thay đổi có tác động.