Overview GitHub Actions là một nền tảng CI/CD miễn phí được tích hợp trực tiếp vào hệ sinh thái GitHub, cho phép người dùng định nghĩa các luồng công việcworkflow tự động hóa nhiều hoạt
Introduction to CI/CD
Understanding Continuous Integration
- Liên t c tích h p, hay CI, là quy trình tích h p t t cụ ợ ợ ấ ả các thay đổi mã code vào nhánh chính c a mủ ột kho lưu trữ mã nguồn sớm và thường xuyên, t ự động kiểm th mử ỗi thay đổi khi commit hoặc merge code, và t ng bắt ự độ đầu một quá trình build CI giúp các nhóm DevOps phát hi n và giải quy t ệ ế xung độ ớm và đảt s m bảo rằng cơ sở mã ngu n vồ ẫn ổn định
- M c tiêu cu i cùng c a CI là cung c p mã ngu n ụ ố ủ ấ ồ hoạt động m t cách nhanh ộ chóng và an toàn Trước khi bắt đầu, có hai điều bạn nên nh : ớ
+ Thứ nhất, chia mã code theo t ng phiên b n nhừ ả ỏ Hầu h t các d án phế ự ần m m, ngay c trong các t ề ả ổchức nh , s ỏ ẽ liên quan đến m t s ộ ố tính năng đang được làm việc b i các thành viên trong nhóm khác nhau Ngay cả trong ở trường hợp tốt nh t, có thể khó cho các thành viên trong nhóm có cái nhìn ấ tổng quan vào những gì người khác đang làm Tình hình tr nên t i tở ồ ệ hơn nếu các nhà phát tri n làm viể ệc trên các nhánh tính năng riêng biệt mà không liên k t, và ch merge vào nhánh chính khi công vi c c a h hoàn thành - và ế ỉ ệ ủ ọ khi đến lúc merge công việc của mọi người lại với nhau, m i th t xung ọ ứ ừ đột mã code đến những vấn đề bất ngờ về security sẽ làm trì hoãn việc release Nhưng nếu mỗi developer y các c p nh t c a mình lên nhánh đẩ ậ ậ ủ chính t ng chút m t, nhóm s ừ ộ ẽtiến gần hơn đến vi c th c hi n CI, v i ít xung ệ ự ệ ớ đột hơn và việc release dễ dự đoán hơn Các quy trình phát triển phần mềm như feature flags có thể giúp các nhóm cung cấp tính năng mới cho người dùng m t cách nhanh chóng và an toàn ộ
+ Thứ hai, thi t l p ki m th t ế ậ ể ử ự động để giữ mã code c a b n an toàn và bủ ạ ảo m t ậ Trước đây, các giai đoạn "build" và "test" trong quá trình phát triển phần m m t n t i m t cách riêng biề ồ ạ ộ ệt, v i mã code ch ớ ỉ được kiểm tra để phát hiện các lỗ hổng an ninh sau khi hoàn thành và s n sàng release Một ph n ẵ ầ cần thi t cế ủa CI là ki m th liên tể ử ục - kiểm th ử mã code để phát hi n l h ng ệ ỗ ổ an ninh trong su t quá trình phát triố ển Nhưng như bạn có thể đoán được, điều này có thể khó để th c hi n th công Đó là lúc ần đếự ệ ủ c n kiểm thử tự động Công cụ CI hiện đại ngày nay lấy mã code mà m developer y lên ỗi đẩ và ch y các bài ki m th ạ ể ử như kiểm th ử đơn vị (unit test) hoặc ki m th tích ể ử hợp (integration test m t cách t ) ộ ự động
Phát tri n ể ứng dụng web nâng cao
- CI làm cho vi c phát tri n ph n m m tr nên d dàng, nhanh chóng và ít rệ ể ầ ề ở ễ ủi ro hơn đối v i các developer B ng cách t ớ ằ ự động hóa quá trình build và kiểm thử, các developer có thể thực hi n nhệ ững thay đổi nh và commit chúng ỏ m t cách t tin Các nhà phát tri n ph n m m nhộ ự ể ầ ề ận được ph n h i vả ồ ề mã code c a h sủ ọ ớm hơn, tăng tốc độ tổng th c a s i mể ủ ự đổ ới
- Các tổ chức áp dụng CI có l i th c nh tranh vì h có th tri n khai nhanh ợ ế ạ ọ ể ể hơn Các tổ chức đã triển khai CI đều tạo ra doanh thu từ các tính năng mà họ tri n khai, không ph i ch ể ả ờ đợi kiểm tra mã code th công ủ
- Các nghiên cứu được th c hi n b i DevOps Research and Assessment ự ệ ở (DORA) đã chỉ ra rằng các thực hành DevOps mạnh mẽ dẫn đến kết quả kinh doanh c i thi n T t c các ch s DORA 4 này có thả ệ ấ ả ỉ ố ể được c i thiả ện bằng cách s d ng CI: ử ụ
+ Ti t ki m th i gianế ệ ờ : Ph n h i s m và tả ồ ớ ự động hóa build/kiểm th giúp ử giảm thời gian t việc commit code đến khi mã code chạy thành công trên ừ môi trường production
+ T n su t tri n khaiầ ấ ể : Ki m th và build tể ử ự động là điều ki n tiên quyệ ết cho vi c tri n khai t ng ệ ể ự độ
Phát tri n ể ứng dụng web nâng cao
+ Thời gian khôi ph c d ch vụ ị ụ: Các pipeline t ự động cho phép s a lử ỗi được triển khai nhanh chóng lên môi trường productn, gi m th i gian trung bình ả ờ để khắc phục (MTTR)
+ Khắc ph c t l l i th t b iụ ỷ ệ ỗ ấ ạ: Ki m th tể ử ự động t s m giừ ớ ảm đáng kể ố s lượng lỗi phát hi n ra khi s n phệ ả ẩm được tri n khai ể
- B ng cách lo i b các nhi m v ằ ạ ỏ ệ ụthủ công, các nhóm DevOps có th làm viể ệc hiệu quả hơn và nhanh chóng hơn Một luồng công việc tự động cũng cải thi n vi c chuy n giao, tệ ệ ể ừ đó tăng cường hiệu quả hoạt động tổng thể Các lợi ích kinh doanh t liên t c tích h p cho phép t ừ ụ ợ ổchức:
+ L p l i nhanh chóngặ ạ : Những thay đổi mã code nh giúp các nhóm phát ỏ tri n ph n m m l p lể ầ ề ặ ại nhanh chóng hơn và dễ quản lý hơn.
+ Dễ dàng phát hi n vệ ấn đề: Các nhóm có th phát hi n vể ệ ấn đề trong mã code vì t t c ấ ả mã code được quản lý và ki m th theo t ng lô nh ể ử ừ ỏ
+ Cải thi n tính minh bệ ạch: Ph n h i liên t c thông qua vi c ki m th ả ồ ụ ệ ể ử thường xuyên giúp các nhà phát tri n nhìn th y v trí c a các lể ấ ị ủ ỗi
+ Giảm chi phí: Ki m th tể ử ự động gi i phóng th i gian cho các nhà phát ả ờ tri n b ng cách gi m các nhi m v ể ằ ả ệ ụthủ công, và chất lượng mã code tốt hơn có nghĩa là ít lỗi hơn và ít thời gian chết máy hơn.
+ Làm hài lòng người dùng: Ít l i và s cỗ ự ố hơn được đưa ra môi trường sản xuất, do đó người dùng có trải nghi m tệ ốt hơn.
- Kiểm th tử ự động gi m khả ả năng xảy ra l i cỗ ủa con người và đảm b o ch ả ỉ có mã code đáp ứng các tiêu chuẩn nhất định mới được triển khai vào môi trường production Bởi vì mã code được ki m th theo t ng lô nh , s ít viể ử ừ ỏ ẽ ệc chuyển đổi ng c nh cho các nhà phát tri n khi m t lữ ả ể ộ ỗi x y ra Các pineline ả cũng có thể xác định nơi xảy ra lỗi, giúp dễ dàng xác định vấn đề và sửa ch a.ữ
- Môi trường phát tri n v i ít nhi m vể ớ ệ ụ thủ công có nghĩa là kỹ sư có thể dành nhi u thề ời gian hơn cho các dự án t o ra doanh thu V i ít lạ ớ ỗi hơn, các nhóm làm vi c hi u qu ệ ệ ả hơn và dành ít thời gian hơn để giải quy t vế ấn đề Khi các quy trình như kiểm thử đơn vị được tự động hóa, các kỹ sư sẽ hạnh phúc hơn và có thể ập trung vào nơi họ t tạo ra giá trị lớn nh ất.
Overview of Continuous Delivery
- Như tên gọi của nó, continuous delivery (CD) là một quy trình phát triển phần m m hoề ạt động cùng v i continuous integration ớ (CI) để ự độ t ng hóa quá trình phát hành ng d ng Các nhà phát tri n ph n m m phát hành cứ ụ ể ầ ề ập nhật mã code trong các chu kỳ ngắn nhưng liên tục bằng việc s d ng t ử ụ ự động hóa để tăng tốc quá trình phát hành CD bao g m t t c ồ ấ ả các bước trong
Phát tri n ể ứng dụng web nâng cao chu k production - build test, c u hình và deploy M c tiêu cu i cùng là ỳ , ấ ụ ố đưa phần mềm vào tay người dùng
- CD có thể được coi là m t ph n m r ng cộ ầ ở ộ ủa CI, đôi khi được đề cập cùng nhau dưới tên CI/CD, đó là quy trình tích hợp mã code vào một kho lưu trữ chung và build/test mỗi thay đổi ngay l p tậ ức, t ự động và thường là một vài lần trong m t ngày ộ
- Sau khi CI xây d ng và ki m th mã code trong mự ể ử ột kho lưu trữ chung, CD tiếp tục trong các giai đoạn cuối để m b o vi c phát hành ph n m m là ít đả ả ệ ầ ề rủi ro, nh t quán và có th l p l ấ ể ặ ại.
- Continuous delivery thường được sử dụng hoán đổi với continuous deployment, nhưng có một sự khác biệt nhỏ giữa hai khái ni m này ệ Continuous deployment có nghĩa là tất cả mã code đã được xác nh n qua CI ậ sẽ triển khai vào môi trường production một cách tự động, trong khi continuous delivery chỉ đơn giản là mã code này có thể được tri n khai S ể ự linh ho t cho vi c tri n khai mã code vào b t k ạ ệ ể ấ ỳthời điểm nào là điểm khác biệt gi a delivery và deployment, và th c hi n continuous deployment ch ữ ự ệ ỉ có th khi continể uous delivery đã được thiết lập trước đó.
Phát tri n ể ứng dụng web nâng cao
- Các nhóm phát tri n s ể ẽnhận th y nhi u l i ích khác khi tri n khai ph n mấ ề ợ ể ầ ềm qua vòng đời phát tri n ph n mể ầ ềm (SDLC - software development lifecycle) Những l i ích này bao gợ ồm:
+ T ng hóa quá trình phát hành ph n m m ự độ ầ ề
+ Chi phí thấp hơn so với phát triển ph n m m truy n thầ ề ề ống
+ Tăng năng suất làm việc
+ Nhanh chóng xác định và giải quyết vấn đề ỗ l i
+ Thời gian đưa sản ph m ra th ẩ ị trường nhanh hơn thông qua việc kiểm thử và phát tri n liên t c ể ụ
Key Components and Workflow
1.3.1 Components of a CI/CD pineline
Mỗi đường ống CI/CD s có d ng khác nhau tùy thu c vào nhu c u và tài nguyên ẽ ạ ộ ầ cụ thể của đội ngũ của bạn, nhưng nó thường bao g m bồ ốn giai đoạn cốt lõi
Build Ở giai đoạn này, bạn lấy mã nguồn từ kho lưu trữ và xây dựng các thành phần của nó thành một đối tượng nhị phân Môi trường phát triển tích h p (IDE) ợ mà b n s d ng có th h ạ ử ụ ể ỗtrợ các nhà phát tri n t ng hóa quá trình này ể ự độTest Trong quy trình CI/CD, b n mu n áp d ng càng nhiạ ố ụ ều
Phát tri n ể ứng dụng web nâng cao kiểm th liên t c càng t t Ki m th ử ụ ố ể ử đơn vị giúp xác minh rằng các tính năng mới hoạt động như ý định, và hầu hết các kiểm thử nên thuộc loại này Kiểm thử hồi quy đảm bảo rằng vi c thêm m i vào mã code không gây ra s cệ ớ ự ố cho cơ sở ạ h tầng hi n t i cệ ạ ủa bạn.
Deliver Sau khi ki m th hoàn t t, mã code c a bể ử ấ ủ ạn nên được triển khai vào môi trường d phòng Điều này giúp b n th c hi n ki m tra A/B và tìm ra các vự ạ ự ệ ể ấn đề còn tồn đọng, đồng thời thông báo cho đội ngũ kiểm thử chất lượng bi t h cế ọ ần kiểm tra nh ng gì ữ
Deploy Khi quá trình xây dựng đã vượt qua t t c các ki m thấ ả ể ử ự t động, nó có thể triển khai vào môi trường s n xu t V i continuous delivery, quá trình xây ả ấ ớ dựng được gửi đến một người dùng để được phê duy t th công, trong khi vệ ủ ới continuous deployment, quá trình xây dựng được tri n khai t ng ể ự độ
GitHub Actions: Overview and Basics
Introduction to GitHub Actions
GitHub Actions là một nền tảng CI/CD miễn phí được tích hợp trực tiếp vào hệ sinh thái GitHub, cho phép người dùng định nghĩa các luồng công việc (workflow) tự động hóa nhiều hoạt động trong phát triển phần mềm như: build, test, deployment
Mỗi workflow trong GitHub Actions là một tập hợp các hành động (actions) được định nghĩa trong file YAML Các actions này có thể là các lệnh cụ thể như: build ứng dụng, test, triển khai ứng dụng Bạn có thể sử dụng các actions được cung cấp sẵn bởi GitHub, các actions mà cộng đồng lập trình viên tạo ra hoặc tạo các actions tùy chỉnh để phù hợp với nhu cầu của dự án của mình
Phát tri n ể ứng dụng web nâng cao
Chúng ta có thể tạo những workflows để build và kiểm thử mỗi pull request đến repository của mình hoặc triển khai các pull request đã được merged lên môi trường production
2.1.2 The Components of GitHub Actions
Có th c u hình m t GitHub Actions ể ấ ộ workflow được g i m i khi x y ra m t s ọ ỗ ả ộ ự kiện (event) trong repository Workflow s bao g m m t ho c nhiẽ ồ ộ ặ ều job (jobs) có thể chạy theo tu n tầ ự hoặc song song M job sỗi ẽ chạy trong máy o riêng ả (virtual machine runner) hoặc trong m t container, có m t ho c nhiộ và ộ ặ ều bước (steps) để chạy một script do người dùng t ự định nghĩa hoặ đểc chạy một action
- extension có th tái s dể ử ụng để đơn giản hoá workflow
Workflow là m t quy trình tộ ự động có th cể ấu hình, ch y m t ho c nhi u jobs ạ ộ ặ ề Workflow được định nghĩa bằng m t tộ ệp YAML được thêm vào repository và s ẽ chạy khi được kích hoạt bởi một event trong repository, ho c chúng có thặ ể được kích hoạt th công ho c theo lủ ặ ịch đã định
Workflows s ẽ được định nghĩa trong thư mục github/workflows trong repository và m t repository có th có nhi u workflow, m i workflow sộ ể ề ỗ ẽ thực hi n m t tệ ộ ập hợp jobs Ví dụ, có th có mể ột workflow để build và test các pull request, một workflow khác để deploy ứng dụng mỗi khi có phiên bản mới và một workflow khác nữa để thêm label mỗi khi có ai đó tạo một issue mới
Chúng ta cũng có thể gọi một workflow trong m t workflow khác.ộ
Event (sự ki n)ệ là một hành động trong repository kích ho t workflow ch y ạ ạ Ví dụ: t o pull request, open issue, push commit ạ
Phát tri n ể ứng dụng web nâng cao
Job (job) là m t t p h p các ộ ậ ợ bước (steps) trong workflow được thực thi trên cùng m runner Một ỗi bước là m t t p l nh sheộ ậ ệ ll script được th c thi ho c m action ự ặ ột được ch y Các ạ bước sẽ thực thi theo th t và ph thu c nhau Vì ứ ự ụ ộ các bước được thực thi trên cùng m t runner nên có thể chia sẻ d ộ ữliệu từ bước này sang bước khác
Ví d , b n có th có mụ ạ ể ột step để build và ti p theo sau là mế ột bước test ứng dụng đã được build
Chúng ta có th c u hình các ph thuể ấ ụ ộc (dependency) gi a 2 jobsữ Mặc định, các job không có phụ thuộc và chạy song song với nhau Nhưng khi một job phụ thu c vào m job khác, nó s ộ ột ẽ đợi job phụ thuộc hoàn thành trước rồi job đó mới chạy
Ví d , b n có nhiụ ạ ều job không ph ụthuộc nhau để các ki n trúc khác nhau, và mế ột job đóng gói phụ thu c vào các job ộ đó Các job build sẽ chạy song song và sau khi t t c hoàn thành, job ấ ả đóng gói mới chạy
M t Action là mộ ột ứng d ng có th custom c a GitHub Actions Action th c hiụ ể ủ ự ện những tác v ụphức tạp nhưng lặp đi lặp lại thường xuyên S dử ụng action để giúp giảm lượng code trong các workflow
Có th t t o action hoể ự ạ ặc tìm các action để s d ng trong workflow trong ử ụ Market Place c a GitHub.ủ
Runner là máy chủ chạy workflow khi chúng được kích ho t M i runner ch có ạ ỗ ỉ thể chạy một job tại m t thộ ời điểm
Github cung cấp các máy ảo Linux, Windows và MacOS để chạy các workflow hoặc bạn có thể tự quản lý các self hosted runner (các máy chủ hoặc máy ảo do - bạn tự quản lý và duy trì) trong data center hoặc cơ sở hạ tầng đám mây của bạn Getting started with GitHub Actions
File định nghĩa workflow sử dụng YAML syntax và phải có một file đuôi yml hoặc yaml Bạn phải lưu file workflow ở đường dẫn “.github/workflows” trong repository của mình
2.1.3 Workflow syntax of GitHub Actions
Sau đây là một s ố YAML syntax cơ bản để cấu hình file workflow: name
Phát tri n ể ứng dụng web nâng cao
Tên của workflow GitHub hiển thị tên của các workflows của bạn trong tab
"Actions" của repository Tên của workflow được đặt ở đầu file
• name: demo-github actions workflow - - on
Sử dụng "on" để xác định sự kiện nào sẽ kích hoạt workflow chạy Để xem danh sách các sự kiện có sẵn, hãy tham khảo Events that trigger workflow
Có thể cài đặt một hoặc nhiều sự kiện có thể kích hoạt workflow, hoặc cài đặt lịch trình thời gian Bạn cũng có thể hạn chế việc thực thi luồng công việc chỉ xảy ra đối với các files, tags hoặc thay đổi ở branch cụ thể
Workflow sẽ chạy mỗi khi có lệnh push ở bất kỳ nhánh nào trong repository
Workflow s ẽchạy m i khi push ho c repository ỗ ặ thực hi n fork Nệ ếu nhi u event xề ảy ra đồng thời, workflow s ẽ được chạy nhi u lề ần.
• on: branch_protection_rule: types:
Workflow s ẽchạy m i khi branch protection rule c a repository b thay ỗ ủ ị đổi
- 'demo branch/**' - Đây là ví dụ cho bi t cách s d ng event filters và ch y workflow ch khi ế ử ụ ạ ỉ event có m t s ộ ố điều ki n nhệ ất định
Phát tri n ể ứng dụng web nâng cao paths:
Ví d trên cho biụ ết làm sao để workflow ch ỉchạy đố ới v i 1 lo i file nhạ ất định, s dụng path filters trên, workflow s ử Ở ẽchỉ kích ho t khi m t file ạ ộ Python được push lên repository defaults Được sử dụng để chỉ định các cài đặt mặc định cho workflow Nếu nó được chỉ định cho một job nhất định thì nó chỉ áp dụng cho một job đó Nếu không, nó sẽ cấu hình cho tất cả các jobs
• defaults: run: shell: bash working directory: demo - -workflow scripts -
Loại Shell mặc định được s d ng khi th c hi n các l nh trong workflow ử ụ ự ệ ệ là bash và khai báo thư mục chứa các tập l nh mà nó ph i ch y ệ ả ạ jobs
GitHub Actions in Action
Building and Testing Applications
3.1.1 About continuous integration using GitHub Actions
- CI s d ng GitHub Actions cung c p các quy trình làm vi c có th xây dử ụ ấ ệ ể ựng mã trong repository c a b n và ch y các bài test Các quy trình làm vi c có ủ ạ ạ ệ thể chạy trên máy ảo được lưu trữ trên GitHub ho c trên các máy mà b n t ặ ạ ự quản lý
- B n có th cạ ể ấu hình quy trình làm vi c CI cệ ủa mình để chạy khi m t s ộ ựkiện GitHub x y ra (ví d , khi code mả ụ ới được đẩy vào repository c a b n), theo ủ ạ lịch trình c ố định, hoặc khi một s ựkiện bên ngoài x y ra b ng cách s dả ằ ử ụng webhook gửi thông báo đến repository
- GitHub ch y các bài ki m tra CI c a b n và cung c p k t qu c a mạ ể ủ ạ ấ ế ả ủ ỗi bài kiểm tra trong pull request, vì v y b n có th xem xét xem s ậ ạ ể ự thay đổi trong nhánh c a b n có l i hay không Khi t t c các bài ki m tra CI trong quy ủ ạ ỗ ấ ả ể trình làm việc đã thành công, các thay đổ ạn đẩi b y lên sẵn sàng được xem xét b i m t thành viên c a nhóm hoở ộ ủ ặc được merge Khi một bài test thất b i, ạ m t trong nhộ ững thay đổ ủi c a b n có th gây ra lạ ể ỗi
- Khi b n thi t l p CI trong repository c a mình, GitHub phân tích code trong ạ ế ậ ủ repository c a bủ ạn và đề xuất quy trình làm vi c CI d a trên ngôn ng và ệ ự ữ framework b n s dạ ử ụng Ví dụ, nếu b n s d ng Node.js, GitHub s ạ ử ụ ẽ đềxuất m t quy trình làm vi c khộ ệ ởi đầu để cài đặt các gói Node.js c a b n và chủ ạ ạy các bài test c a b n Bủ ạ ạn có th s d ng quy trình làm vi c khể ử ụ ệ ởi đầu CI được đề xuất bởi GitHub, tùy chỉnh quy trình làm việc khởi đầu được đề xuất, hoặc t o t p quy trình làm vi c tùy ch nh c a riêng bạ ệ ệ ỉ ủ ạn để chạy các bài kiểm tra CI c a bủ ạn
- Ngoài vi c giúp b n thi t l p các quy trình làm vi c CI cho d án c a b n, ệ ạ ế ậ ệ ự ủ ạ bạn có th s dể ử ụng GitHub Actions để ạ t o các quy trình làm vi c tr i dài ệ ả suốt vòng đời phát tri n ph n m m Ví d , b n có th s d ng các hoể ầ ề ụ ạ ể ử ụ ạt động để triển khai, đóng gói hoặc phát hành d án c a b n ự ủ ạ
3.1.2 Build and test Node.js
S d ng starter workflow Node.js ử ụ
- Để bắt đầu nhanh chóng, thêm một starter workflow vào thư mục github/workflows của repository c a bủ ạn
- GitHub cung c p mấ ột starter workflow cho Node.js có thể hoạt động cho hầu h t các d án Node.js ế ự
1 Trên trang GitHub.com, điều hướng đến trang chính của repository
2 Dưới tên của repository, nh p vào Actions ấ
Phát tri n ể ứng dụng web nâng cao
3 Nếu bạn đã có một workflow trong repository của bạn, nh p vào New ấ workflow
4 Trang "Choose a workflow" hi n th m t s l a ch n các ể ị ộ ố ự ọ starter workflow được đề xuất Tìm ki m "Node.js" ế
5 Lọ ực l a ch n các workflow b ng cách nh p vào Continuous integration ọ ằ ấ
6 Trên workflow "Node.js", nh p vào Configure ấ
7 Chỉnh s a workflow theo nhu cầu c a b n Ví dử ủ ạ ụ, thay đổi các phiên bản Node.js mà b n mu n s dạ ố ử ụng
Tệp workflow node.js.yml được thêm vào thư mục github/workflows của repository c a bủ ạn
Xác định phiên bản Node.js
- Cách dễ nhất để xác định phiên bản Node.js là sử dụng action setup-node được cung c p b i GitHub ấ ở
- Action setup-node nh n phiên bậ ản Node.js làm đầu vào và c u hình phiên ấ bản đó trên runner Action setup-node tìm phiên b n cả ụ thể ủ c a Node.js t ừ bộ nhớ cache công cụ trên mỗi runner và thêm các binary c n thi t vào ầ ế PATH, điều này t n t i cho ph n còn l i cồ ạ ầ ạ ủa job S d ng action setup-node ử ụ là cách được khuy n ngh ế ị để s d ng Node.js vử ụ ới GitHub Actions vì nó đảm bảo hành vi nh t quán trên các runner khác nhau và các phiên b n khác nhau ấ ả của Node.js N u bế ạn đang sử dụng một runner tự host, bạn phải cài đặt Node.js và thêm nó vào PATH
- Starter workflow bao g m mồ ột matrix build và test code c a b n v i các ủ ạ ớ phiên bản Node.js được li t kê trong node-version 'x' trong s phiên b n là ệ ố ả m t ký tộ ự đại di n cho phiên b n ph và b n vá m i nh t có s n cho mệ ả ụ ả ớ ấ ẵ ột phiên b n M i phiên b n Node.js cả ỗ ả ụ thể được chỉ định trong m ng node-ả version t o ra mạ ột job chạy các bước tương tự
Mỗi job có thể truy cập vào giá trị được xác định trong mảng `node-version` của matrix bằng cách sử dụng matrix context Action `setup-node` sử dụng ngữ cảnh này như là đầu vào `node-version` Action `setup-node` cấu hình mỗi job với một phiên bản Node.js khác nhau trước khi build và test code.
Phát tri n ể ứng dụng web nâng cao node-version: ['14.x', '16.x', '18.x'] steps:
- name: Use Node.js ${{ matrix.node-version }} uses: actions/setup-node@v3 with: node-version: ${{ matrix.node-version }}
B n c ng có th dùng phiên b n Node.js chính xác ạ ũ ể ả strategy: matrix: node-version: ['10.17.0', '17.9.0']
Hoặc b n cạ ũng có th s d ng 1 phi bể ử ụ ên ản Nodejs duy nh t ấ name: Node.js CI on: [push] jobs: build: runs-on: ubuntu-latest steps:
- name: Use Node.js uses: actions/setup-node@v3 with: node-version: '20.x'
- run: npm run build if -present
Building and testing your code
Phát tri n ể ứng dụng web nâng cao steps:
- name: Use Node.js uses: actions/setup-node@v3 with: node-version: '20.x'
- run: npm run build if -present
Deploying with GitHub Actions
Kích ho t vi c tri n khai c a b n ạ ệ ể ủ ạ
B n có th s d ng nhi u loạ ể ử ụ ề ại s ựkiện để kích hoạt deployment workflow c a b n ủ ạ
M t s s ộ ố ựkiện ph ổbiến nh t là: pull_request, push, và workflow_dispatch ấ
Ví dụ, một quy trình v i các trigger sau ch y khi: ớ ạ
- Pull request hướng tới nhánh main được mở, đồng bộ hóa hoặc m lở ại
- Người nào đó kích hoạt nó một cách thủ công on: push: branches:
S dử ụng môi trường (environments)
Môi trường được s dử ụng để mô t m t m c tiêu triả ộ ụ ển khai chung như production, staging ho c development Khi mặ ột workflow của GitHub Actions triển khai đến một môi trường, môi trường đó sẽ được hi n th trên trang chính cể ị ủa repository
B n có th s dạ ể ử ụng môi trường để yêu c u phê duyầ ệt để job p t c, h n ch tiế ụ ạ ế những nhánh nào có th kích ho t mể ạ ột workflow, cài đặt quy t c b o v tri n khai ắ ả ệ ể tùy ch nh, ho c h n ch truy c p vào bí m t ỉ ặ ạ ế ậ ậ
Phát tri n ể ứng dụng web nâng cao
Concurrency đảm bảo chỉ có một công việc hoặc quy trình sử dụng cùng nhóm concurrency s ẽchạy vào m t thộ ời điểm Bạn có th s dể ử ụng concurrency để đảm bảo một môi trường có tối đa một vi c triệ ển khai đang diễn ra và một vi c triệ ển khai đang chờ vào m t thộ ời điểm
Lưu ý: concurrency và environment không có liên kết Giá tr concurrency có th ị ể là b t k chu i nào; không c n phấ ỳ ỗ ầ ải là tên môi trường Ngoài ra, n u mế ột workflow khác s d ng cùng mử ụ ột môi trường nhưng không chỉ định concurrency, workflow đó sẽ không ph i tuân th b t k quy t c concurrency nào ả ủ ấ ỳ ắ
Ví d , khi workflow sau ch y, nó s b t m d ng v i tr ng thái ch n u b t k ụ ạ ẽ ị ạ ừ ớ ạ ờ ế ấ ỳ job hoặc workflow n s dào ử ụng nhóm concurrency production đang diễn ra Nó cũng sẽ hủy bỏ bất kỳ job hoặc workflow nào s d ng nhóm concurrency ử ụ production và có tr ng thái chạ ờ Điều này có nghĩa là sẽ có tối đa một job đang chạy và m t job ộ đang chờ ử ụ s d ng nhóm concurrency production name: Deployment concurrency: production on: push: branches:
- main jobs: deployment: runs-on: ubuntu-latest environment: production steps:
# các bước tri n khai c ể ụ thể
Bạn cũng có thể chỉ định concurrency tại job level Điều này s cho phép các job ẽ khác trong workflow p t c ngay c khi job tiế ụ ả cùng nhóm đang chạy đang chờ name: Deployment
Phát tri n ể ứng dụng web nâng cao on: push: branches:
- main jobs: deployment: runs-on: ubuntu-latest environment: production concurrency: production steps:
# các bước triển khai cụ thể
Bạn cũng có thể sử dụng cancel-in-progress để hủy bỏ bất kỳ job hoặc workflow đang chạy nào trong cùng nhóm concurrency name: Deployment concurrency: group: production cancel- -progress: true in on: push: branches:
Phát tri n ể ứng dụng web nâng cao jobs: deployment: runs-on: ubuntu-latest environment: production steps:
# các bước triển khai cụ thể
Khi một workflow c a GitHub Actions triủ ển khai đến một môi trường, môi trường đó sẽ được hi n th trên trang chính cể ị ủa repository
Theo dõi c workflow ác đang chạy
M workflow khi ch y t o ra m t biỗi ạ ạ ộ ểu đồ thời gian th c minh h a ti n trình ự ọ ế chạy B n có thể s d ng biạ ử ụ ểu đồ này theo dõi và gỡ l i các quy trình tri n để ỗ ể khai
Bạn cũng có thể xem các logs của mỗi workflow và l ch s các workflow ị ử Theo dõi các tri n khai thông qua các ng dể ứ ụng
Nếu tài kho n cá nhân ho c tả ặ ổ chức c a bủ ạn trên GitHub.com được tích hợp với Microsoft Teams ho c Slack, b n có th theo dõi các tri n khai s d ng môi ặ ạ ể ể ử ụ trường thông qua Microsoft Teams ho c Slack Ví d , b n có th ặ ụ ạ ểnhận thông báo qua ứng d ng khi m t vi c triụ ộ ệ ển khai đang chờ được phê duy t, khi m t vi c triệ ộ ệ ển khai được phê duy t, ho c khi tr ng thái triệ ặ ạ ển khai thay đổi
Bạn cũng có thể xây d ng mự ột ứng d ng s d ng các webhook tri n khai và trụ ử ụ ể ạng thái triển khai để theo dõi các tri n khai Khi m t công vi c quy trình làm viể ộ ệ ệc mà tham chiếu đến một môi trường ch y, nó t o ra mạ ạ ột đối tượng tri n khai vể ới thuộc tính môi trường được thi t l p thành tên cế ậ ủa môi trường c a b n Khi quy ủ ạ trình làm vi c ti n triệ ế ển, nó cũng tạo ra các đối tượng tr ng thái tri n khai vạ ể ới thuộc tính môi trường được thi t l p thành tên cế ậ ủa môi trường c a b n, thu c tính ủ ạ ộ environment_url được thiết lập thành URL cho môi trường (nếu được chỉ định trong quy trình làm vi c), và thuệ ộc tính state được thi t l p thành tr ng thái cế ậ ạ ủa công vi c ệ
Phát tri n ể ứng dụng web nâng cao
B n có th ạ ểchạy quy trình làm vi c tri n khai c a mình trên các runner do GitHub ệ ể ủ cung c p ho c trên các runner tấ ặ ự host Lưu lượng từ các runner do GitHub cung cấp có thể đến t m t loừ ộ ạt địa chỉ mạng khác nhau Nếu bạn triển khai đến một môi trường nội bộ và công ty của bạn hạn chế lưu lượng ngoại vi vào các mạng riêng, quy trình làm vi c c a GitHub Actions ch y trên các runner do GitHub ệ ủ ạ cung cấp có th không th giao ti p vể ể ế ới các dịch vụ hoặc tài nguyên n i b của ộ ộ bạn Để khắc phục điều này, b n có th t host các runner c a riêng b n ạ ể ự ủ ạ Hiển th m t huy hi u tr ng thái ị ộ ệ ạ
B n có th s d ng m t huy hi u trạ ể ử ụ ộ ệ ạng thái để hiển thị trạng thái của quy trình làm vi c triệ ển khai c a b n M t huy hi u tr ng thái s cho bi t li u m t quy trình ủ ạ ộ ệ ạ ẽ ế ệ ộ làm việc đang thất bại hay đang thành công Một nơi phổ biến để thêm huy hiệu trạng thái là trong t p README.md cệ ủa kho lưu trữ ủ c a bạn, nhưng bạn có th ể thêm nó vào b t k trang web nào b n mu n Theo mấ ỳ ạ ố ặc định, huy hi u s ệ ẽhiển th ị trạng thái c a nhánh mủ ặc định c a b n Bủ ạ ạn cũng có thể hiển thị trạng thái của m t ch y quy trình làm vi c cho mộ ạ ệ ột nhánh ho c sặ ự kiện cụ thể ằ b ng cách s ử dụng các tham s truy v n branch và event trong URL ố ấ
Best Practices in CI/CD
CI/CD Tips
Nếu b n mu n thành công v i CI/CD, hãy biạ ố ớ ến continuous integration, delivery, and deployment thành phương châm của b n vì chúng là n n t ng c a các thạ ề ả ủ ực hành phát tri n ph n m m M c tiêu cể ầ ề ụ ủa DevOps là đưa phần mềm đến người dùng nhanh hơn so với các phương pháp truyền th ng và các th c hành phát triố ự ển này s ẽ giúp làm điều đó trở thành sự thật
Nếu b n h i 10 nhóm DevOps v ạ ỏ ề quan điểm c a h v các th c hành t t nh t củ ọ ề ự ố ấ ủa CI/CD, ch c ch n b n sắ ắ ạ ẽ nhận được 10 câu tr l i khác nhau Tuy nhiên, có mả ờ ột số mẹo được đồng thuận rộng rãi:
- Chỉ build m t l nộ ầ : Đừng build mới cho mỗi giai đoạn vì bạn có nguy cơ gây ra s không nhự ất quán Thay vào đó, thúc đẩy các build artifacts giống nhau qua từng giai đoạn c a CI/CD pinelineủ Điều này yêu c u m t quá trình ầ ộ xây d ng không ph thuự ụ ộc vào môi trường
- Tối ưu hóa kiểm thử: Đạt được s cân b ng gi a ph m vi ki m th và hiự ằ ữ ạ ể ử ệu suất N u ki m th m t quá nhi u thế ể ử ấ ề ời gian, người dùng s c g ng né tránh ẽ ố ắ quá trình này
Phát tri n ể ứng dụng web nâng cao
- G p s cặ ự ố nhanh chóng: Ở phía CI, các nhà phát triển đang commit code cần biết càng s m càng t t n u có vớ ố ế ấn đề để ọ h có thể quay l code và sại ửa chữa nó khi ý nghĩa của vi c sệ ửa chưa được đặt ra Ý tưởng "g p s c nhanh ặ ự ố chóng" giúp gi m thiả ểu vi c chuyệ ển đổi ng cữ ảnh của nhà phát triển, điều này làm cho các chuyên gia DevOps hạnh phúc hơn.
- Thực hiện hàng ngày: Mức độ thường xuyên c a các commit code càng ủ cao, nhóm DevOps s ẽnhận thấy được nhiều lợi ích hơn.
- S a ch a n u nó b hử ữ ế ị ỏng: CI/CD làm cho vi c s a ch a các bệ ử ữ ản build bị hỏng tr ở nên đơn giản
- Làm sạch môi trường trước production: Càng lâu môi trường được giữ hoạt động, vi c theo dõi t t cệ ấ ả các thay đổ ấi cu hình và c p nhậ ật đã được áp dụng càng trở nên khó khăn hơn Điều này là động l c tự ốt để làm s ch môi ạ trường trước production giữa mỗi l n tri n khai ầ ể
- Tự động hóa m i lúcọ : Ti p tế ục điều ch nh CI/CD pineline ỉ để đảm bảo đạt được trạng thái "t ng hóa liên t c" ự độ ụ
- Hiểu rõ các bước: Đảm bảo kế hoạch release và rollback được tài li u hóa ệ rõ ràng và được hiểu rõ bởi toàn b nhóm ộ
- Đảm b o an toàn: CI/CD là một shift left (Shift left is the practice of ả moving testing, quality, and performance evaluation early in the development process, often before any code is written), do đó nó cung cấp một cơ hộ ốt đểi t tích hợp bảo mật sớm hơn trong quá trình.
- Vòng l pặ : Đảm bảo có một cách dễ dàng để toàn bộ nhóm nhận (và đóng góp vào) ph n hả ồi.
CD Best practices
- Bắt đầ ừ nơi ủu t c a bạn: Đừng ch ờ đợi m t n n t ng m i Luôn có th ộ ề ả ớ ể điều chỉnh nh ng gì bữ ạn có để làm cho nó nhanh hơn và hiệu quả hơn
- Ít là nhi uề : CD t t nhố ất được th c hi n v i s ự ệ ớ ố lượng công c t i thiụ ố ểu
- Theo dõi những gì đang diễn ra: Vấn đề và yêu c u merge có thầ ể trở nên không ki m soát N u có l a ch n v các c t m c (milestone), chúng có th ể ế ự ọ ề ộ ố ể hữu ích Thêm vào đó, các cột mốc có thể có tác dụng gấp đôi khi thiết lập các sprints Agile và các phiên bản.
- Triển khai thay đổi tự động: Tối ưu hóa acceptance testing người dùng và tạo môi trường v i t ng hóa ớ ự độ
- Quản lý release pineline: T ự động hóa là câu tr l ả ời.
- Thiết l p theo dõiậ : Theo dõi quá trình production m t cách t t giúp tiộ ố ết kiệm thời gian và ti n bề ạc Nó cũng có thể cung cấp các điểm dữ liệu chính cho phía kinh doanh
Phát tri n ể ứng dụng web nâng cao
- Khởi động tri n khai liên tể ục: Khi CD đang diễn ra, mang l i sạ ự tri n khai ể rảnh tay khi có th gể ửi các thay đổi đến sản xuất một cách t ng ự độ
How to improve the CI/CD pipeline?
- Kết h p chiợ ến lược phát hành M t phiên bộ ản canary (đôi khi được g i là ọ canary deployment) có thể đáng xem xét Trong một phiên b n canary, các ả tính năng mới được tri n khai ch ể ỉ đến một nhóm người dùng c ụthể
- Thêm nhi u ki m th t ng vì không bao gi ề ể ử ự độ ờ có đủkiểm th t ng ử ự độ
- Ti p t c thu g n Ít công cế ụ ọ ụ hơn có nghĩa là ít bước chuyển giao hơn Nếu CI/CD là m t ph n c a mộ ầ ủ ột nền t ng DevOps, m i th s ả ọ ứ ẽ được t p trung tậ ại một nơi.
Measure the success of CI/CD
Nhóm DevOps không thể biết được hi u su t c a th c hành CI/CD c a hệ ấ ủ ự ủ ọ đang diễn ra như thế nào trừ khi h ọ đo lường chúng Các ch s ỉ ố đóng vai trò quan trọng trong việc cải thi n hi u su t hệ ệ ấ ệ thống và giúp xác định nơi có thể thêm giá trị Chúng cũng cung cấp một cơ sở để đo lường tác động của bất kỳ cải tiến nào được th c hiự ện.
Dưới đây là các chỉ số tốt nhất để ử ụ s d ng:
Thời gian chu kỳ Đây là thời gian mất bao lâu để triển khai một ứng dụng chức năng từ khi công việc trên mã bắt đầu Để xác định thời gian chu kỳ trung bình, đo lường các giai đoạn quá trình phát tri n Chỉ s này sẽể ố cung c p cái nhìn vấ ề thời gian phát tri n ể tổng th và bể ất k ỳ điểm nghẽn nào trong quá trình
Thời gian đạt giá tr ị Đây là thời gian mất để phát hành mã đã viết Quá trình tích hợp, kiểm thử, giao hàng và tri n khai nên m t t ể ấ ừ vài phút đến vài gi ờ để hoàn thành chu k ỳkiểm thử Nếu m t nhiấ ều ngày để di chuy n m t b n xây d ng qua CI/CD pineline, thể ộ ả ự ời gian để đạt giá tr ị không được th c hi n và quy trình cự ệ ần được điều chỉnh Thời gian hoạt động
Thời gian hoạt động là ch s ỉ ố đo lường tính ổn định và đáng tin cậy cũng như việc m i th ọ ứhoạt động như mong muốn Đây là một trong những ưu tiên lớn nh t cấ ủa nhóm v n hành Khi chiậ ến lược CI/CD đượ ự động hóa, các lãnh đạo vận hành c t
Phát tri n ể ứng dụng web nâng cao có th t p trung nhiể ậ ều hơn vào tính ổn định c a hủ ệ thống và ít thời gian hơn cho các vấn đềluồng công việc.
Tỷ l lệ ỗi ứng d ng là m t ph n không th tránh kh i trong quá trình phát tri n ụ ộ ầ ể ỏ ể Theo dõi chúng r t quan tr ng vì không ch t l l i có thấ ọ ỉ ỷ ệ ỗ ể chỉ ra vấn đề ề chất v lượng, mà còn các vấn đề liên quan đến hi u su t và thệ ấ ời gian hoạt động Nếu thời gian hoạt động và t l l i có vỷ ệ ỗ ẻ cao, điều này có th minh h a m t thách ể ọ ộ thức CI/CD ph ổbiến gi a nhóm phát tri n và v n hành M c tiêu v n hành là mữ ể ậ ụ ậ ột chỉ s quan tr ng c a thành công quy trình ố ọ ủ
Chi phí cơ sở hạ tầng
Chi phí cơ sở hạ tầng rất quan trọng trong phát triển cloud native Triển khai và quản lý m t n n tộ ề ảng CI/CD có th gây ra chi phí l n nể ớ ếu không được kiểm soát Để xác định cách họ sẽ thi t lập giá cả của mình, các nhà cung cế ấp đám mây sẽ xem xét chi phí ph n c ng m ng, bầ ứ ạ ảo trì cơ sở hạ tầng và lao động
Giữ chân nhóm Điều này không ph i là bí n: Khi m t nhà phát triả ẩ ộ ển hoặ- c b t k ai, th c s - ấ ỳ ự ự cảm thấy được đánh giá và hài lòng, họ ẽ có xu hướ s ng lở ại Khi các nhóm làm việ ốc t t cùng nhau và biết cách h p tác, vi c giợ ệ ữ chân cũng có khả năng xảy ra Ngược lại, nhà phát tri n có th c m th y không tho i mái khi phát bi u ý kiể ể ả ấ ả ể ến nếu họ không thích cách vi c diệ ễn ra, nhưng nhìn vào tỷ ệ giữ chân có th giúp l ể xác định các vấn đề tiề ẩm n.
Benefits of following CI/CD best practices
- Các nhà phát tri n không ch s a l i, h ể ỉ ử ỗ ọ đang viết mã Ít công c và chuụ ỗi công cụ có nghĩa là ít thời gian b ra cho b o trì và nhi u thỏ ả ề ời gian hơn để thực s t o ra các ng d ng ph n m m chự ạ ứ ụ ầ ề ất lượng cao
- Mã được triển khai Thay vì đợi trong hàng đợi, mã thực sự được đưa ra thế giới thực Điều này cũng dẫn đến s h nh phúc c a các nhà phát triự ạ ủ ển
- Các nhà phát tri n có th i gian và t p trung vào vi c gi i quy t các vể ờ ậ ệ ả ế ấn đề kinh doanh Một quy trình CI/CD được tối ưu hóa giúp các nhà phát tri n t p trung vào nh ng vể ậ ữ ấn đề quan tr ng và không ph i mọ ả ất th i gian cho ờ mã l i, vi c b lỗ ệ ỏ ỡ bước chuy n giao, các vể ấn đề ả s n xuất và nhi u về ấn đề khác
- Việc đổi mới dễ dàng hơn Đó là một thế giới c nh tranh, và các tạ ổ chức cần tất cả các công c có sụ ẵn để duy trì vị thế Một quy trình CI/CD được xây d ng t t giúp vi c phát tri n ph n m m tr nên d dàng, nhanh chóng ự ố ệ ể ầ ề ở ễ
Phát tri n ể ứng dụng web nâng cao và an toàn hơn, điều này có nghĩa là nhóm DevOps có thời gian và năng lượng để nghĩ ra những giải pháp sáng tạo.
- Thu hút và gi chân nhân tàiữ Đó là một th ị trường lao động cạnh tranh và tài năng DevOps có thể rất khó để làm hài lòng Không có gì nói lên "chúng tôi nghiêm túc v i nhóm DevOps cớ ủa chúng tôi" hơn là mộ ổ chức đã đầu t t tư vào công nghệ và quy trình xung quanh CI/CD
- Mọi người đều làm nh ng gì hữ ọ giỏi nhất Phát tri n, v n hành, b o mể ậ ả ật và ki m th mể ử ỗi người đều có vai trò quan tr ng, và CI/CD giúp phân rõ ọ trách nhi m c a tệ ủ ừng người.
Custom Actions in GitHub Actions
Introduction and guide to creating custom actions
B n có th t o các actions b ng cách vi t nhạ ể ạ ằ ế ững đoạn code tương tác với repository tùy vào nhu c u c a b n B n có th tầ ủ ạ ạ ể ự viết nh ng actions dùng ữ để trong workflow c a mình ủ hoặc chia sẻ những actions v i cớ ộng đồng GitHub Để chia sẻ những action v i mớ ọi người, repository c a b n phủ ạ ải ở chế độ công khai Actions có th ểchạy trực ti p trên m t máy ho c trong m t Docker container Bế ộ ặ ộ ạn có th ể định nghĩa inputs, outputs và biến môi trường của actions
Có 3 lo i action: Docker container action, JavaScript action và action h n hạ ỗ ợp
- Docker container actions: Các container Docker đóng gói môi trường cùng v i mã nguớ ồn GitHub Actions Điều đó giúp đảm b o sả ự nhất quán và tin cậy vì người dùng action không c n ph i lo l ng v các công c ầ ả ắ ề ụhoặc các ph ụ thu c ộ liên quan
Container Docker cho phép b n s d ng các phiên b n cạ ử ụ ả ủa hệ điều hành, thư viện ph thu c và công c c ụ ộ ụ ụthể Vì thế, đối v i nh ng action c n chớ ữ ầ ạy trong một môi trường phải được c u hình cấ ụ thể thì Docker là l a ch n lý ự ọ tưởng vì b n có thạ ể tùy chỉnh h điệ ều hành và công cụ Tuy nhiên, do độ trễ trong quá trình build và l y container, action s d ng container Docker ấ ử ụ thường chậm hơn action sử dụng JavaScript Thêm n a, Docker Container Action ch có th ữ ỉ ểthực thi trên các runner với hệ điều hành Linux Self-hosted Runner phải dùng hệ điều hành Linux và cài đặt Docker để chạy các hành động container Docker
- JavaScript actions: JavaScript Action có th ểchạy tr c ti p trên runner, và ự ế tách bi t code c a action vệ ủ ới môi trường dùng để chạy code đó Sử ụ d ng JavaScript Action sẽ giúp đơn giản hóa code c a action và th c thi nhanh ủ ự
Phát tri n ể ứng dụng web nâng cao hơn so với Docker container action Để đả m bảo JavaScript action tương thích với tất cả các lo i runner của ạ GitHub (Ubuntu, Windows, macOS), code JavaScript nên là JavaScript thu n và không ph thu c vào các t p nh phân khác ầ ụ ộ ệ ị
- Action h n h p (composite actions)ỗ ợ : cho phép k t h p nhiế ợ ều bước workflow trong m t action Ví d , b n có thộ ụ ạ ể dùng tính năng này để gói nhi u l nh ch y thành mề ệ ạ ột action, sau đó có một workflow th c thi các ự lệnh đã được gói lại như một bước duy nhất bằng cách gọi action đó 5.1.2 Create and use a custom action
Trong hướng dẫn này, chúng ta sẽ tìm hiểu cách để xây dựng một JavaScript action N u b n mu n tìm hi u thêm v các cách t o các lo i actions khác, có th ế ạ ố ể ề ạ ạ ể xem ở đâyCreating a Docker container actionhoặc Creating a composite action Chu ẩ n b ị
Tải xuống và cài đặt Node.js 20.x (bao gồm cả npm).
Tạo m t repository công khai trên GitHub có tên "hello-world-javascript-action".ộ Clone repository đó về máy
Khởi tạo file package.json b ng lằ ệnh npm init -y.
Tạo một file đặt tên là action.yml hoặc action.yaml (tên b t bu c) v i nắ ộ ớ ội dung sau: name: 'Hello World' description: 'Greet someone and record the time' inputs: who-to-greet: # id of input description: 'Who to greet' required: true default: 'World' outputs: time: # id of output description: 'The time we greeted you' runs: using: 'node20' main: 'index.js'
File này xác định đầu vào who-to-greet và đầu ra time Nó cũng cho runner biết làm sao để chạy action này
Phát tri n ể ứng dụng web nâng cao
Action toolkit là một bộ các gói Node.js cho phép xây dựng các action nhanh chóng với độ nhất quán cao hơn
Trong terminal, chạy 2 lệnh sau để cài đặt toolkit core và github npm install @actions/core npm install @actions/github
Action này s l y biẽ ấ ến đầu vào who- -greet to từ file metadata Sau đó, in ra một thông báo debug trong log v i n i dung ớ ộ “Hello [who-to-greet]” Tiếp theo, action sẽ l y th i gian hi n tấ ờ ệ ại và lưu trữ nó như một bi n output Các action ế tiếp theo trong cùng job có th truy c p và s dể ậ ử ụng bi n này.ế
Thêm file index.js, có nội dung sau: const core = require('@actions/core'); const github = require('@actions/github'); try {
// `who- -greet` input defined in action metadata file to const nameToGreet = core.getInput('who-to-greet'); console.log(`Hello ${nameToGreet}!`); const time = (new Date()).toTimeString(); core.setOutput("time", time);
// Get the JSON webhook payload for the event that triggered the workflow const payload = JSON.stringify(github.context.payload, undefined, 2) console.log(`The event payload: ${payload}`);
} catch (error) { core.setFailed(error.message);
Commit, tag và push action c a b n lên GitHub ủ ạ
GitHub s t i xu ng và ch y t ng action trong workflow ẽ ả ố ạ ừ như một gói code hoàn chỉnh trong runtime trước khi b n có th dùng các lạ ể ệnh workflow như run để tương tác với các runner Điều đó có nghĩa action c n ch a t t c các gói ph ầ ứ ấ ả ụ thu c c n thiộ ầ ết để chạy code JavaScript Vì th , b n nên ki m tra xem gói core và ế ạ ể github đã được thêm vào repository chưa
Commit các tệp và thư mục sau: action.yml, index.js, node_modules, package.json và package-lock.json Lưu ý bạn phải commit cả folder node_modules (kiểm tra trong file gitignore): git add action.yml index.js node_modules/* package.json package-lock.json git commit -m "My first action is ready" git tag -a -m "My first action release" v1.1 git push follow-tags
Phát tri n ể ứng dụng web nâng cao
Push cả thư mục node_modules có th gây ra vể ấn đề Để khắc ph c, có th s ụ ể ử dụng tool @vercel/ncc để biên d ch code ị JavaScript và đóng gói các gói phụ thuộc của nó thành m t file duy nh t ộ ấ
Test th ử action trong workflow
Bây giờ, đã sẵn sàng để test action trong m t workflow ộ
Sau đây là một ví dụ cách sử dụng một action công khai (public action): Copy đoạn code YAML sau vào github/workflows/main.yml
Lưu ý: Cập nhật đoạn uses: octocat/hello world javascript action@v1.1 - - - bằng username của bạn on: [push] jobs: hello_world_job: runs-on: ubuntu-latest name: A job to say hello steps:
- name: Hello world action step id: hello uses: octocat/hello-world-javascript-action@v1.1 with: who-to-greet: 'Mona the Octocat'
# Use the output from the `hello` step
- name: Get the output time run: echo "The time was ${{ steps.hello.outputs.time }}"
Khi workflow này được kích hoạt, runner sẽ tải xuống action hello world - - javascript-action từ repository công khai của bạn và thực thi nó
Nếu bạn muốn sử dụng các action private thì phải dựa vào quyề truy cập trong cài đặt của repository:
Cùng repository chứa action: Chỉ các workflow trong cùng repository mới có thể sử dụng action
Các repository khác cùng user/ organization: Action có thể được sử dụng bởi các workflow trong repository khác thuộc sở hữu của cùng user hoặc organization Tham khảo: Managing GitHub Actions settings for a repository
Publishing and Utilizing actions in GitHub Marketplace
5.2.1 Publish an action in GitHub Marketplace
B n có th publish m t action do b n t o vào GitHub Marketplace b ng cách gạ ể ộ ạ ạ ằ ắn thẻ nó là new release và publish nó
Phát tri n ể ứng dụng web nâng cao
Follow theo các bước sau:
1 Tại GitHub.com, vào trang chính c a repository ủ
2 Truy c p vào t p metadata c a action trong repository (action.yml hoậ ệ ủ ặc action.yaml) và b n s ạ ẽthấy một banner để publish action lên Marketplace Click vào Draft a release
3 Bên dưới “Release Action”, chọn Publish this Action to the GitHub Marketplace
4 Nếu các nhãn trong t p metadata c a bệ ủ ạn có b t k vấ ỳ ấn đề nào, b n s ạ ẽthấy thông báo l i N u không, b n sỗ ế ạ ẽ thấy thông báo "Everything looks good!"
5 Chọn danh m c trong ụ Primary Category s giúp mẽ ọi người tìm được action c a b n d ủ ạ ễ dàng hơn trong GitHub Marketplace
6 Tùy ch n, b n có th ọ ạ ểchọn danh mục phụ trong Another Category
7 Trong trường tag, hãy nh p phiên b n c a action ậ ả ủ
8 Trong trường title, hãy nhập tiêu đề ủ c a b n phát hành ả
9 Điền hết các trường còn l i và click ạ Publish release
Nếu b n mu n tìm hi u v cách gạ ố ể ề ỡ các action đã publish trong GitHub Marketplace, tham khảo Publishing actions in GitHub Marketplace
5.2.2 Utilize actions from GitHub Marketplace
Tìm ki m và xem action ngay trong workflow editor ế
B n có th tìm ki m và xem qua các action tr c ti p trong workflow editor ạ ể ế ự ế của repository Sidebar, bỞ ạn có thể tìm m t action cộ ụ thể, xem các action nổi bật và duy t qua các danh m c B n còn có th xem s ệ ụ ạ ể ố sao mà action đó đạt được từ cộng đồng GitHub
1 Trong repository, tìm đến file workflow mà b n muạ ốn ch nh sỉ ửa.
2 Phía bên trên bên ph i, click vào m editor ả để ở
3 Bên phía bên phải của editor, sử dụng Marketplace trong sidebar để tìm kiếm các action
Phát tri n ể ứng dụng web nâng cao
Thêm action t Marketplace vào workflow ừ
Trong trang danh sách các action s bao g m c phiên b n c a action và workflow ẽ ồ ả ả ủ syntax cần thiết để s dử ụngcho action đó Để khiến cho workflow làm việc được ổn định ngay c khi có c p nhả ậ ật gì đó cho m t action, b n có th tham chi u phiên ộ ạ ể ế bản của action b ng cách chằ ỉ định tag number của Git ho c Docker trong file ặ workflow Để ử ụ s d ng các action trong marketplace, bạn làm các bước sau:
1 Tìm đến action mà b n mu n s dạ ố ử ụng trong marketplace
2 Nhấp để xem thông tin đầy đủ ủa action đó c
3 Bên dưới “Installation”, nhấp để copy thông tin cài đặt được viết theo workflow syntax
Phát tri n ể ứng dụng web nâng cao
4 Thêm đoạn vừa copy như một bước của workflow Nếu bạn muốn hiểu rõ hơn về cách thêm, tham khảo Workflow syntax for GitHub Actions.
5 Nếu action yêu c u ph i có input, hãy thêm input cho nó ầ ả Để workflow hoạt động ổn định, bạn cũng có thể bật tự động cập nhật phiên bản Dependabot cho các action mà b n thêm vào workflow Truy cạ ập Keeping your actions up to date with Dependabot đểhiểu chi tiết hơn.
Real-world case study of the implementation of CI/CD
Vấn đề: Case study bắt đầu v i vi c m t công ty ớ ệ ộ thương mại điện t ử đã có uy tín đối mặt với thách th c chung của k nguyên kỹ thu t sứ ỷ ậ ố Đó là nhu cầu đổi mới và cung c p cấ ác tính năng cũng như cập nh m i cho các cật ớ ửa hàng tr c tuyự ến của mình m t cách nhanh chóng Trong m t thộ ộ ị trường có tính c nh tranh cao, ạ tốc độ tiếp c n thậ ị trường và s nhanh chóng là nh ng y u t quan tr ng có th ự ữ ế ố ọ ể khi n h ế ọtrở nên khác bi t so vệ ới các đối th c nh tranh Tuy nhiên, quy trình phát ủ ạ tri n ph n m m hi n t i c a h g p khó kể ầ ề ệ ạ ủ ọ ặ hăn do quy trình deploy và testing thủ công ch m, dậ ẫn đến s ựchậm tr trong vi c cung cễ ệ ấp các tính năng mới và s a lử ỗi cho khách hàng
Phát tri n ể ứng dụng web nâng cao
Giải pháp DevOps: Tích hợp liên t c và tri n khai liên t c (CI/CD): Để ảụ ể ụ gi i quy t nh ng thách thế ữ ức đó, công ty đã áp d ng các nguyên tụ ắc DevOps, tập trung vào vi c tri n khai các quy trình Tích h p liên t c (CI) và Tri n khai liên tệ ể ợ ụ ể ục (CD) Đây là cách họ đã làm điều đó:
- Automated Testing: H ọ đã tự động hóa quy trình kiểm thử của mình, đảm bảo r ng mằ ọi thay đổi mã đều được t ự động th c hi n m t lo t các bài kiự ệ ộ ạ ểm thử đơn vị, kiểm thử tích h p và kiợ ểm thử h i quy (regression tests) ồ Điều này cho phép xác định nhanh chóng các khiếm khuyết và vấn đề, giảm nguy cơ lỗi xâm nh p vào ậ môi trường production
- Version Control: Họ đã áp dụng hệ thống ki m soát phiên b n m nh m ể ả ạ ẽ (như Git) để theo dõi các thay đổi mã, cho phép các nhà phát tri n c ng tác ể ộ liền mạch và đảm bảo rằng cơ sở mã vẫn ổn định và có thể bảo trì
- CI/CD Pipelines: quy trình CI/CD được triển khai để tự động hóa toàn b ộ quy trình phân ph i ph n m m Developer s commit code c a h lên ố ầ ề ẽ ủ ọ repository c a version control, ủ điều đó sẽ kích ho t quy trình CI/CD Quy ạ trình bao gồm các giai đoạn như build ng d ng, t ng test và tri n khai ứ ụ ự độ ể ứng dụng đến môi trường chạy thử (staging environment) để thử nghiệm thêm
- Deployment Automation: Ph n CD (Continuous Deployment) c a quy ầ ủ trình bao g m tri n khai tồ ể ự động sang production sau khi các thay đổi đã vượt qua tất cả các th nghiử ệm trong môi trường ch y th Quá trình triạ ử ển khai t ự động này đã loạ ỏi b nhu c u can thi p th công, giầ ệ ủ ảm nguy cơ xảy ra l i cỗ ủa con người
Thành qu :ả Việc triển khai quy trình CI/CD có tác động mạnh m n quy trình ẽ đế phân ph i ph n m m cố ầ ề ủa công ty thương mại điện tử:
- Thời gian ti p thế ị nhanh hơn: Thời gian c n thiầ ết để cung cấp các tính năng và bản cập nhật mới đã giảm đáng kể Những gì trước đây phải mất hàng tuần ho c th m chí hàng tháng gi ặ ậ ờ đây có thể được th c hi n ch trong ự ệ ỉ vài ngày ho c vài gi ặ ờ
- Phần m m chề ất lượng cao hơn: Kiểm tra và tri n khai tể ự động c i thiả ện đáng kể chất lượng phần mềm Các lỗi và sự cố đã được phát hiện sớm trong quá trình phát tri n, giúp h n ch ể ạ ếviệc s a lỗi sau phát hành ử
- Cải thi n s ệ ựphối h pợ : Quy trình CI/CD khuy n khích s h p tác gi a các ế ự ợ ữ nhóm Developer và Operation Tính minh b ch cạ ủa quy trình cho phép mọi người thấy được tiến trình thay đổi từ development sang production
- Tăng s hài lòng c a khách hàngự ủ : V i viớ ệc phát hành nhanh hơn và giảm số lượng l i, s hài lòng cỗ ự ủa khách hàng đã tăng vọt Trang web thương mại điện t mang l i tr i nghi m mua sử ạ ả ệ ắm mượt mà hơn, đáng tin cậy hơn
Phát tri n ể ứng dụng web nâng cao
- L i th c nh tranh: ợ ế ạ Công ty đạt được lợi thế cạnh tranh nhờ có thể đáp ứng nhanh chóng nhu c u thị ầ trường, những thay đổi theo mùa và các xu hướng trending m i n i Hớ ổ ọ có thể triển khai các tính năng nhằm đáp lại phản h i cồ ủa khách hàng nhanh hơn bao giờ hết
K t lu nế ậ : Case study điển hình này minh h a s c m nh biọ ứ ạ ến đổ ủi c a Tích hợp liên t c và Tri n khai liên t c (CI/CD) trong th ụ ể ụ ếgiới DevOps B ng cách t ằ ự động hóa các quy trình th nghi m và triử ệ ển khai, công ty thương mại điện t này có thử ể tăng tốc phân phối phần mềm, cải thiện chất lượng phần mềm và luôn dẫn đầu trong th ị trường c nh tranh Nó nh n m nh th c t r ng CI/CD không ch là mạ ấ ạ ự ế ằ ỉ ột công ngh mà còn là m t sệ ộ ự thay đổi văn hóa có thể cách m ng hóa cách phát ạ tri n, th nghi m và phân ph i ph n m m Trong thể ử ệ ố ầ ề ời đạ ỹi k thu t s phát triậ ố ển nhanh chóng, các tổ chức s d ng CI/CD có vử ụ ị thế ốt hơn để đáp ứng mong đợi t của khách hàng và phát tri n m nh trên th ể ạ ị trường.