Trang tài liệu Trí Nam

Debug là việc khó gấp đôi code. Nếu viết code thông minh quá mức, bạn sẽ không đủ thông minh để debug nó

Tuyển dụng
Updated on Tháng năm 22, 2024

Quy trình chung

Estimated reading: 8 minutes 765 views
DevFlow 5.2
Quy trình dev Core 5.2

Tổng quan về quy trình dev

Quy trình dev core 5.2 hướng đến việc tự động hóa, sử dụng các công cụ Jira (quản lý công việc), GitLab (quản lý source code, CI CD, Review code…) và Telegram / Email / Skype (nhận thông báo thủ công hoặc tự động)

Chi tiết

1. Nhận task

Nguyên tắc:

  • Chỉ làm các task có độ ưu tiên highest
  • Chỉ làm các task đã list trên jira, không nhận ngang các task qua lời nói của BA, Tester
  • Nếu có nhiều task highest thì chọn độ ưu tiên ngẫu nhiên, hoặc leader sẽ lưu ý

Estimate và lên giải pháp sơ bộ:

  • Đổi trạng thái task sang wait for estimate
  • Làm rõ yêu cầu với BA, Tester (người tạo task)
  • Dev chủ động đánh giá tính hợp lý của yêu cầu (yêu cầu quá phức tạp, yêu cầu phù hợp thực tế người sử dụng, yêu cầu bị trùng lặp…). Sau khi đánh giá nếu thấy chưa thể thống nhất được với người tạo task thì cần trao đổi với quản lý cấp cao hơn (leader nhóm, quản lý dự án….) để thống nhất. Dev có thể chủ động đề xuất phương án bố trí chức năng thay thế tương đương nhưng đạt hiệu quả tốt hơn (hiệu quả về thời gian thực hiện, hiệu quả về công năng sử dụng).
  • Sau khi làm rõ yêu cầu nghiệp vụ, làm việc với leader nhóm hoặc quản lý dự án để thống nhất giải pháp thực hiện chức năng.
  • Sau khi thống nhất về giải pháp, dev đưa ra estimate và thống nhất với leader nhóm hoặc quản lý dự án.
  • Điền estimation vào phần comment. Ví dụ 4h

2. Tạo branch để dev

  • Tạo branch mới từ branch chính của core (ví dụ dùng Core version 5.2 thì tạo branch từ dev_5.2)
  • Nguyên tắc đặt tên branch:
    • Nếu là task thì đặt tên là feature/<id task jira>-<mô tả ngắn gọn về task>. Ví dụ: feature/DTCQLNS-1675-bo-sung-truong-trong-dot-cap-nhat-hs
    • Nếu là bug thì đặt tên là hotfix/<id bug jira>-<mô tả ngắn gọn về task>. Ví dụ: hotfix/DTCQLNS-1693
  • Đổi task sang trạng thái in progress
  • Trong quá trình dev thường xuyên push code lên branch đã tạo để bảo toàn code

3. Tạo Merge request

Khi dev gần xong thì tạo MR vào branch dev_5.2 để hệ thống review và test tự động trước một phần. Cụ thể:

  • Tự động build thử project, dựa trên file thay đổi thuộc FE hay BE thì sẽ build project tương ứng. Cụ thể:
    • BE sẽ build thử project API hoặc project Client (Sdk)
    • FE sẽ build thử project application hoặc project service (sdk)
  • Review coding convention với sonarqube:
    • BE sẽ kết hợp review tự động sử dụng roslyn
    • FE sẽ kết hợp review tự động sử dụng eslint
  • Chạy unit test BE (nếu có)
  • Chạy unit test FE (nếu có)
  • Nếu bất ký job nào trong pipeline MR bị lỗi thì dev cần chủ động sửa trước khi thông báo cho reviewer.
  • Sau khi sửa hết các lỗi thì đổi trạng thái task sang Wait for review, cập nhật link pipeline vào comment task và gửi link task jira cho reviewer
  • Reviewer dựa trên thông tin về task trên jira, review thêm các logic nâng cao mà dev đã làm (review về coding convention nâng cao, lỗi logic, lỗi bảo mật, lỗi performance…)
  • Nếu reviewer có comment, thì review xong sẽ thông báo lại cho dev, dev chủ động sửa và đảm bảo pipeline sau khi sửa thành công, khi đó lại thông báo để reviewer kiểm tra lần 2
  • Lặp lại các bước trên cho đến khi MR được reviewer approve và merge vào branch chính.

Danh sách Reviewer hiện tại (theo độ ưu tiên):

  • LinhDH
  • NamNH
  • LyLD

4. Triển khai dev environment

  • Sau khi MR được merge vào branch chính, 1 pipeline nữa được sinh ra để tiến hành release phiên bản mới tương ứng với code đã sửa
  • Dev theo dõi trạng thái của pipline, nếu chạy thành công đến bước release thì dev sẽ click để triển khai lên môi trường test tương ứng mà mình đang làm việc
    • Mỗi một dự án – môi trường sẽ là 1 job độc lập
    • Dev chủ động triển khai lên môi trường – dự án mà mình làm việc để triển khai
    • Dev sử dụng token được cấp để triển khai
  • Dev theo dõi trạng thái triển khai, nếu triển khai thành công thì sẽ có 1 job automation e2e test được tạo ra để test sơ qua một lượt toàn bộ hệ thống phiên bản mới, từ đây nếu có lỗi thì dev sẽ chủ động sửa nếu cần
    • Cần tạo branch riêng để sửa, vì branch cũ đã được merge và xóa
    • Nguyên tắc đặt tên  branch thì giống như bug
  • Nếu phần e2e test không có lỗi, và dev chủ động kiểm tra chức năng của mình đã lên, thì chuyển tạng thái task trên jira thành resolved

5. Verify trên test environment

  • Tester hàng ngày filter các task trên jira có trạng thái resolved, tìm link pipeline tương ứng với task, sau đó bấm triển khai lên môi trường test tương ứng
    • Mỗi một dự án – môi trường sẽ là 1 job độc lập
    • Tester cần được cấp token để có thể triển khai
    • Tester sử dụng 1 token riêng để triển khai
  • Sau khi bấm triển khai trên gitlab, một job automation e2e test được tạo ra để test sơ qua một lượt toàn bộ hệ thống phiên bản mới, từ đây nếu có lỗi thì tester chủ động log bug theo kết quả test tự động
  • Tester test thêm các trường hợp nghiệp vụ để log bug thêm nếu cần
  • Nếu task đã ok thì chuyển sang trạng thái closed

6. Triển khai lên môi trường Stagging

Đang cập nhật…

7. Triển khai lên môi trường Prod

Đang cập nhật…

CONTENTS