Từng Bước Trở Thành Dev Front End Xịn (Phần 4)

Tiếp theo Phần 3: Code coverage với Istanbul của loạt bài viết về Front End, trong bài viết này mình giới thiệu đến các bạn Phần 4: Ứng dụng mẫu User Management, Build và Deploy với Firebase Hosting và Phần 5: Automation Test (AUT) với Puppeteer.

Với các dự án lớn trong thực tế thì Phần 5 có trước Phần 4 nên có sau, tuy nhiên đối tượng của bài viết này là các bạn chưa quen thuộc với quy trình như vậy nên mình sẽ nói về Phần 4 trước để các bạn có môi trường thực hiện Phần 5.

Ứng dụng mẫu User Management, Build và Deploy với Firebase Hosting

Ở các phần trước bạn đã làm quen với việc tạo dự án, implement, UT và code coverage. Tất cả những công đoạn này đều làm ở môi trường phát triển. Sau các công đoạn này các bạn còn một vài công đoạn liên quan đến testing nữa, tuy nhiên liên quan trực tiếp với Dev thì đó là công đoạn Integration testing. Ở công đoạn này, dự án sẽ ghép tất cả các thành phần được phát triển bởi các Dev khác nhau, các teams khác nhau, cả Front End, Back End, để kiểm thử xem ứng dụng có pass qua được các test cases gần giống với thực tế nhất không. Công đoạn này thông thường được gọi là kiểm thử ở môi trường Staging.

Vì là công đoạn gần với môi trường thực tế nên ứng dụng của bạn cũng cần phải được Build, Deploy, ... lên môi trường tương tự với môi trường Product nhất. Công đoạn Build, Deploy sản phẩm lên môi trường Staging hay Deploy sản phẩm lên môi trường Product nằm ngoài phạm vi của Dev team. Công đoạn này đòi hỏi nhiều kiến thức khác mà Dev team không có đủ như: kiến thức mạng, kiến thức bảo mật, kiến thức vận hành server, kiến thức monitoring, ... rất rất là nhiều kiến thức mà Dev team chưa được chuẩn bị. Ngày nay chúng ta hay nghe từ CI/CD đó là từ ngữ chỉ về team làm việc ở công đoạn này.

Ở bài viết này mình không có tham vọng giới thiêu đến các bạn những kiến thức, công cụ liên quan đến lĩnh vực đó. Tuy nhiên để tiếp tục bài viết này và cung cấp cho các bạn một cái nhìn sơ lược về quá trình Build, Deployment mình giới thiệu bạn 2 môi trường khá ổn với chi phí "$0 trọn đời" nhé.

• Môi trường BackEnd: nếu bạn muốn có một server nho nhỏ với chi phí $0 trọn đời thì bạn có thể chọn https://heroku.com/, bạn có thể tham khảo Free Tier của Heroku ở đây: https://www.heroku.com/pricing. Bạn chú ý sau 30 phút không có request nào từ ngoài vào server bạn thì server bạn sẽ bị đưa về trạng thái tạm dừng hoạt động cho đến khi có 1 request mới. 
• Môi trường FrontEnd cho các ứng dụng SPA: tương tự BackEnd nếu bạn muốn có một server nho nhỏ với chi phí $0 cho công việc của mình, bạn có thể sử dụng Firebase Hosting. Free Tier của nó bạn có thể tìm hiểu ở đây: https://firebase.google.com/pricing, Firebase tốt hơn Heroku là nó Free nhưng server không bị tạm dừng hoạt động, nhưng nhược điểm là Firebase Hosting chỉ deploy được web tĩnh, không deploy được code phía BackEnd như NodeJS, Java, ... Ở đây mình chỉ đề cập vấn đề Hosting Free thôi nhé, còn Firebase rất là mạnh và nó hỗ trợ rất nhiều service, tính hợp tốt với Google Cloud Platform, bạn tìm hiểu thêm nếu muốn.
• Database: Bạn dùng Firebase luôn nha, Free Tier của Firebase Database khá là tốt, đủ để bạn làm rất nhiều việc.

Dự án lên Firebase Hosting:

Trong ví dụ này mình sẽ lấy source code mẫu, build và deploy lên Firebase Hosting.

Trước khi xem và làm thử bạn nên

• Tạo 1 google account
• Tải source code mẫu

cd $PROJECT_HOME

# Lệnh này sẽ checkout duy nhất branch FullSample
git clone --single-branch --branch FullSample https://github.com/lapth/FE-User-Management.git

cd FE-User-Management

npm install

Hy vọng với 2 phần hướng dẫn này bạn có thể nắm được cách hoạt động và deploy dự án lên server một cách thuận lợi. Chúng ta tạm dừng công đoạn deployment ở đây để bước qua một công đoạn khác cũng khá là thú vị.

Automation Test (AUT) với Puppeteer

AUT là quá trình kiểm thử ứng dụng của bạn trên môi trường Integration một cách tự động, chúng ta sẽ chạy AUT với dữ liệu và test cases đã định sẵn, sau đó kiểm tra kết quả được trả về từ ứng dụng xem khớp với dữ liệu đã được định nghĩa không.

Không phải dự án nào cũng làm AUT, so với UT thì AUT mất thời gian hơn nhiều và AUT ở các dự án khác nhau sẽ có chiến lược thực hiện khác nhau. AUT đặc biệt mang lại lợi ích lớn với các dự án lớn, thời gian phát triển dài và nhiều người cùng tham gia.

Để hiểu rõ hơn chúng ta xem ví dụ sau:

• Dự án của bạn có khoảng 50 cùng tham gia phát triển, dự án của bạn có khoảng 2000 test cases.
• Câu hỏi đặt ra ở đây là làm sao bạn biết được một Dev nào đó khi đẩy code lên repository của dự án, code đó không phá hỏng 2000 test case đó, không ảnh hưởng đến các chức năng của 49 người còn lại? ... 
• Tất nhiên không ai đủ công sức để làm bằng tay cả ^_^, ở dự án mình từng làm khi một bạn Dev đẩy code lên, hệ thống CI/CD sẽ đi Build, Deploy một môi trường Integration ứng với code mới đưa lên đó, chạy các AUT cho smoke test, sanity test, regression test để đảm bảo code mới được đưa lên đủ tốt để tiếp tục.

Tương tự UT, để thực hiện AUT chúng ta cũng phải tạo ra một phần code mới để kiểm tra chính sản phẩm của mình đã làm ra.

Hiện nay có rất nhiều công cụ giúp bạn làm AUT: Selenium Framework, Robot Framework, Thư viện Puppeteer, ... mỗi công cụ đều có những ưu nhược điểm riêng. Khi chọn một bộ nào đó để sử dụng cho dự án, chúng ta cần cân nhắc đến nhiều điểm, một trong những điểm bạn có thể cân nhắc đến:

• Cộng đồng sử dụng và cộng đồng nhà phát triển: nếu là Open source thì những yếu tố này khá quan trọng, nó đánh giá mức độ tốt xấu cũng như khả năng fix lỗi của Open source đó.
• Tài liệu: tài liệu có đầy đủ không, trong quá trình phát triển bạn rất cần tham khảo tài liệu liên quan, nếu tài liệu tốt thì nó sẽ giải quyết rất nhiều vướng mắc cho dự án.
• Tính năng: framework được chọn có đủ những tính năng mà dự án đang cần không, ví dụ: tạo test suites, chạy test, report, tích hợp các hệ thống khác, ...
• Programming language: team của bạn đang mạnh về ngôn ngữ đó không? cần bao lâu để mọi người sẵn sàng làm việc với ngôn ngữ đó, ...
• Yêu cầu về môi trường làm việc: framework đó cần những gì để hoạt động, cấu hình đơn giản hay phức tạp, yêu cầu phần cứng cao không, ...
• Hỗ trợ trình duyệt nào: framework có hỗ trợ những trình duyệt bạn đang cần không?
• OS: framework chạy được trên các hệ điều hành nào?
• Thời gian thực hiện: framework chạy các test cases, test suites có nhanh không

Trong bài này mình chọn Puppeteer để làm AUT.

Cài đặt và chạy thử AUT:

git clone https://github.com/lapth/AUT-User-Management.git

cd AUT-User-Management

npm install

npm run test

Phần AUT này có 3 test cases:

• Tạo 1 user mới: User 1
• Xóa User đầu tiên
• Sửa tên User đầu tiên thành User 1

Khi bạn chạy phần AUT này, bạn sẽ thấy ứng dụng bật browser lên ở địa chỉ https://usermanagement-sample.firebaseapp.com/ để thực hiện việc kiểm thử. Bạn có thể thay bằng địa chỉ bạn đã deploy ở phần trên để thử.

Lời kết

Cám ơn bạn đã theo dõi loạt bài viết của mình về quy trình phát triển phần mềm ở phía Front End, thông qua loạt bài này mình hy vọng đưa đến các bạn những kiến thức hữu ích khi phát triển sản phẩm, những khái niệm về những công nghệ, công đoạn khi phát triển một dự án lớn cần có, để các bạn có một cái nhìn sơ lược về nó, biết được mình đang thiếu phần nào để học tập bổ sung hoàn thiện dần.

Tuy đã chăm chút từng câu chữ nhưng không thể nào không sai sót, mong các bạn phản hồi bên dưới, mình sẽ sửa đổi để làm bài viết tốt hơn cho người đọc.

Bonus: các bạn nên google "Fullstack Roadmap 2020" hay "Front End Roadmap 2020", ... để biết thêm những công nghệ bản thân nên có để phát triển tốt career path của mình. Các bài đó tương tự bài này: Fullstack Roadmap 2019

Chúc các bạn thành công!

Cre: lapth

---

Những kiến thức về testing, deployment hay quy trình làm việc sẽ thực sự dễ hiểu hơn khi bạn được trực tiếp tham gia vào một dự án thật. Đây cũng là lý do nhiều sinh viên IT hiện nay tìm kiếm môi trường thực chiến từ sớm để tích lũy kinh nghiệm. Nếu bạn muốn trải nghiệm quy trình phát triển phần mềm thực tế thay vì chỉ học lý thuyết, Internship OneConnect (IOC) sẽ là môi trường phù hợp để bắt đầu.