Sớm hay muộn, tất cả chúng ta đều phải xử lý các biến môi trường trong tệp soạn của mình. Chúng có thể trở thành một nỗi đau, đặc biệt nếu chúng ta không biết cách sử dụng chúng đúng cách. Dưới đây là mọi thứ tôi biết về các biến môi trường và cách sử dụng các biến này dễ dàng và trên hết là an toàn.

Chúng ta sử dụng các biến môi trường như thế nào?

Docker Compose cho phép chúng ta chuyển các biến môi trường vào thông qua dòng lệnh hoặc xác định chúng trong trình bao của chúng ta. Tuy nhiên, tốt nhất là giữ các giá trị này bên trong tệp soạn thực tế và bên ngoài dòng lệnh. “Tại sao?” bạn có thể yêu cầu.

Bởi vì theo cách này, chúng ta không phải nhớ tất cả các biến môi trường mà chúng ta sử dụng mỗi khi triển khai vùng chứa của mình. Bằng cách lưu trữ chúng trong tệp soạn, chúng ta duy trì tính nhất quán trong quá trình xây dựng của mình.

Có nhiều hướng khác nhau để làm điều đó.

Sử dụng lựa chọn môi trường.

Sử dụng tùy chọn môi trường soạn cho phép chúng ta khai báo các biến môi trường và giá trị của chúng bên trong tệp soạn của chúng ta, như thế này.

Đây là cách dễ nhất, nhanh nhất để lưu trữ các biến môi trường bên trong soạn tệp. Tuy nhiên, nó có một nhược điểm lớn là liên quan đến bảo mật. Bạn có đoán được nó là gì không?

Đúng rồi.

Việc lưu trữ các giá trị của các biến môi trường của bạn trong tệp Soạn sẽ – 95% thời gian – chuyển thẳng đến kiểm soát nguồn và đó là một rủi ro bảo mật rất lớn. May mắn thay, chúng ta có một giải pháp thay thế: sử dụng tệp bên ngoài để lưu trữ các biến môi trường của chúng ta.

Sử dụng tập tin .env

Ưu điểm chính của việc sử dụng tệp bên ngoài cho các biến môi trường của bạn là bạn có thể giữ tệp đã nói ngoài quyền kiểm soát nguồn của mình. Rốt cuộc, không ai thích có mật khẩu, khóa API hoặc thông tin siêu bí mật khác của họ trên internet.

Tệp .env là tệp văn bản thuần túy, chúng ta sử dụng để cấu hình. Hãy nhớ rằng, vì tên tệp bắt đầu bằng dấu ‘ . ’ Nên chúng vẫn bị ẩn đối với hệ thống.

Chú ý: Để liệt kê các tệp ẩn, bạn có thể sử dụng lệnh ls -a trên Linux hoặc lệnh dir / a: h trên Windows.

Bạn phải tạo tệp .env tại thư mục gốc của dự án, đây cũng là nơi chứa tệp docker-compost.yml của bạn.

Chúng ta có thể khai báo và gán các biến trong tệp .env của mình. Đặt tên cho các biến theo cách bạn muốn vì chúng ta sẽ chỉ truy cập các giá trị của chúng.

 Đây là tệp .env của tôi:

Bạn cũng có thể tạo và điền tệp .env của mình từ dòng lệnh bằng cách sử dụng lệnh mèo Linux:

Chú ý: Hãy nhớ không để lại bất kỳ khoảng trống nào giữa dấu = và giá trị được gán cho biến của bạn, vì chúng sẽ được thêm vào chuỗi.

Bây giờ chúng ta đã lưu trữ các biến trong tệp .env, hãy sử dụng chúng trong tệp Soạn của chúng ta. Bây giờ là lúc sử dụng phép nội suy chuỗi (đó là một cái tên ưa thích khi sử dụng ký hiệu $ {string}) để gán giá trị của các biến .env của chúng ta cho các biến môi trường trong tệp Soạn.

Như bạn có thể thấy, chúng ta duy trì tùy chọn môi trường và chỉ cần gán các giá trị bên ngoài của chúng ta cho các biến môi trường Soạn.

Để kiểm tra xem mọi thứ có hoạt động bình thường hay không, hãy chạy lệnh sau: docker-compile up.

Chú ý: Bạn có thể kiểm tra giá trị nào được gán cho các biến môi trường bằng cách chạy lệnh sau (trong một thiết bị đầu cuối khác): docker-compile config.

Mức độ ưu tiên biến môi trường

Một điều rất quan trọng mà chúng ta phải ghi nhớ là mức độ ưu tiên được Compose sử dụng để lựa chọn giá trị môi trường của nó. Điều đó có nghĩa là gì?

Nếu chúng ta khai báo cùng một biến môi trường trong một số tệp (ví dụ: trong tệp Soạn và trong tệp .env bên ngoài) với các giá trị khác nhau, thì Soạn sẽ sử dụng giá trị của biến được khai báo trong tệp Soạn. Tại sao? Bởi vì, tùy thuộc vào nơi mà biến được khai báo, Soạn sẽ cấp cho biến đó mức độ ưu tiên cao hơn hoặc thấp hơn. Đây là thứ tự, xếp hạng từ mức độ ưu tiên cao nhất đến mức độ ưu tiên thấp nhất:

1. Soạn tệp
2. Biến môi trường Shell
3. Tệp môi trường
4. Dockerfile
5. Biến không được xác định

Nếu vì lý do nào đó, tính năng Soạn đang chọn và chỉ định một giá trị mà bạn không mong đợi, thì đây có thể là nguyên nhân. Đảm bảo rằng tất cả các biến của bạn được khai báo chính xác ở nơi bạn muốn.

Sử dụng tùy chọn env file

Trong phần trước, chúng ta đã nói về các tệp .env thuần túy, nhưng chúng ta chưa bao giờ sử dụng các tệp .env có tên. Nếu chúng ta muốn tệp .env của mình có tên, như secret-things.enf, thì Compose có một tùy chọn nhỏ tiện lợi có tên là env_file.

Tùy chọn này cho phép chúng ta thông báo cho soạn thảo tệp .env mà nó phải tìm kiếm, trái ngược với hành vi mặc định của nó, đó là tìm kiếm tệp .env không tên. Đây là cách chúng ta sử dụng tùy chọn env_file.

Như bạn có thể thấy, chúng ta đã thêm tùy chọn env_file, tùy chọn này trỏ đến một tệp có tên tệp secret -uff.env. Tất cả những gì còn lại là đổi tên tệp .env trước đó của chúng ta thành secret -uff.env.

Bạn có thể nhận thấy tùy chọn môi trường không còn xuất hiện trong tệp soạn thư của chúng ta. Điều này là do việc sử dụng tùy chọn env_file làm nảy sinh một vấn đề – một vấn đề khiến tôi khá đau đầu!

Để gán các giá trị được khai báo trong tệp .env có tên bên ngoài cho các biến soạn yêu cầu tệp đã nói phải được xác định trong dịch vụ soạn chính. Điều này liên quan đến thứ tự mà Soạn tuân theo khi thực hiện các hoạt động. Tuy nhiên, chúng ta không có dịch vụ chính, vì chúng ta chỉ sử dụng một dịch vụ db. Do đó, nếu chúng ta cố gắng triển khai tệp Soạn của mình, nó sẽ phàn nàn rằng các biến của chúng ta không được xác định và thay thế chúng bằng các chuỗi trống.

Bạn không cần phải nghe lời tôi, hãy tiếp tục và thử nó! Chạy docker-soạn lên và xem điều gì sẽ xảy ra.

Vì vậy, làm thế nào để chúng ta giải quyết vấn đề này? Đây là những gì tôi đã tìm ra:

Nếu chúng ta xóa tùy chọn môi trường khỏi tệp soạn, khi triển khai, soạn sẽ tìm kiếm tệp secret -uff.env được chỉ định, điều mà tùy chọn này không thực hiện khi có tùy chọn môi trường. Vấn đề đã được giải quyết!

Tuy nhiên, hãy nhớ rằng vì chúng ta không còn tùy chọn môi trường nữa, chúng ta phải khai báo các biến môi trường trực tiếp trong tệp secret -uff.env, như sau:

Một lần nữa, để kiểm tra xem mọi thứ có hoạt động bình thường hay không, hãy chạy: docker-compile up.

Đây các cách khác nhau để xử lý an toàn với các biến môi trường trong soạn tệp. Cảm ơn đã theo dõi.

Author: DuongVT19

Ngày càng có nhiều công ty nghe thấy tiếng còi báo động của đám mây. Với chi phí khởi động thấp và dễ dàng thiết lập cơ sở hạ tầng, tại sao lại không?

Nhưng khả năng loại bỏ phần cứng tại chỗ để chuyển sang sử dụng đám mây – nơi người khác phải tham gia vào việc bảo trì và cập nhật máy chủ – vẫn đòi hỏi các chuyên gia có thể làm cho mọi thứ hoạt động trơn tru.

Chính xác thì kiến trúc sư đám mây là gì?

“Khi bạn nghĩ về một kiến ​​trúc sư, bạn sẽ nghĩ đến một người nào đó thiết kế các tòa nhà và lên kế hoạch xây dựng chúng như thế nào; Meg Yahl, kỹ sư đám mây tại Uncomn, một công ty dịch vụ tư vấn công nghệ và quản lý doanh nghiệp cho biết.

Cụ thể hơn, một kiến ​​trúc sư đám mây giúp một công ty phát triển, thực hiện và duy trì chiến lược điện toán đám mây của mình. Họ cần có hiểu biết sâu sắc về nhu cầu, ràng buộc, quy định ngành và mục tiêu của công ty họ vì nó liên quan đến điện toán đám mây.

Susanne Tedrick, chuyên gia cơ sở hạ tầng đám mây tại Nền tảng điện toán đám mây Azure của Microsoft và trước đây là chuyên viên kỹ thuật tại IBM Cloud. Mặc dù bản thân không phải là kiến ​​trúc sư đám mây, Tedrick hợp tác chặt chẽ với các kiến ​​trúc sư đám mây trong quá trình giúp khách hàng sử dụng và di chuyển đám mây.

Cô nói thêm rằng vai trò của kiến trúc sư đám mây đòi hỏi kiến thức kỹ thuật rất sâu về điện toán đám mây và các lĩnh vực bổ trợ như mạng máy tính, dữ liệu và bảo mật.

Một số tiêu đề thường trùng lặp hoặc được coi là có thể hoán đổi cho nhau với các kiến trúc sư đám mây. Chúng bao gồm các kỹ sư đám mây và kiến trúc sư giải pháp trong các công ty hoặc phòng ban cụ thể về đám mây. Ví dụ: mặc dù chức danh của Yahl là kỹ sư đám mây – với các kỹ sư đám mây có xu hướng là những người thực hiện các thiết kế và kế hoạch do kiến trúc sư đám mây phát triển – cô ấy thường xuyên thực hiện cả các công việc dành riêng cho kỹ sư và kiến trúc sư.

Tedrick ghi nhận phần lớn các biến thể tiêu đề và sự trùng lặp trong vai trò kiến trúc sư đám mây đối với sự phát triển nhanh chóng của nó khi việc áp dụng đám mây ngày càng phát triển.

Bà nói: “Đặc biệt khi có những chuyên ngành phụ trong lĩnh vực này, các công ty sẽ thường kết hợp vai trò kiến trúc sư với trách nhiệm kỹ sư hoặc kỹ thuật viên.

Không chỉ tương tác với đám mây

Nói chung, trải nghiệm hàng ngày của kiến ​​trúc sư đám mây sẽ xoay quanh việc xác định, đáp ứng và thực hiện nhu cầu đám mây của công ty hoặc khách hàng, Tedrick nói. Điều này có thể có nghĩa là dẫn đầu các cuộc thảo luận chuyên sâu về kỹ thuật, xác nhận rằng giải pháp đám mây sẽ đáp ứng các yêu cầu của công ty hoặc xác định các cách giải quyết tiềm năng, phát triển sơ đồ kiến ​​trúc và giúp phát triển bằng chứng về công nghệ và bằng chứng về khái niệm cho khách hàng. Đôi khi, nó cũng có thể liên quan đến việc cung cấp sản phẩm chung và giáo dục điện toán đám mây.

Đối với Frank Dagenhardt – kiến ​​trúc sư giải pháp cho Zscaler, một công ty bảo mật thông tin dựa trên đám mây – giáo dục những người khác về đám mây là một tính năng thường xuyên trong những ngày của ông. Điều này có thể liên quan đến việc viết sách trắng và bài đăng trên blog, hoặc tổ chức hội thảo trên web của nhóm người dùng trong ngành. Và các nỗ lực giảng dạy có thể hướng đến đối tượng nội bộ như nhân viên của Zscaler hoặc đối tác hoặc khách hàng bên ngoài.

“Chúng tôi làm việc dựa trên sự hỗ trợ cho các nhóm nội bộ của chúng tôi và các đối tác của chúng tôi mà chúng tôi làm việc cùng – đảm bảo rằng họ hiểu các giải pháp, biết cách chúng hoạt động, những loại giải pháp khác nhau mà chúng tôi có thể giúp khách hàng và cách họ sẽ giúp khách hàng, ” Anh nói.

Gặp gỡ khách hàng cũng là một phần chính trong các ngày của Dagenhardt. Anh và nhóm của mình thảo luận với khách hàng về nhu cầu của họ và cách đạt được những nhu cầu đó một cách tốt nhất. Các cuộc họp này thường tạo ra các ý tưởng để cải tiến các sản phẩm và dịch vụ của Zscaler, thông qua yêu cầu của khách hàng hoặc nhóm xác định các tính năng chung có thể phục vụ khách hàng tốt hơn.

Dagenhardt cho biết: “Nếu có những khoảng trống về tính năng mà chúng tôi có thể mắc phải hoặc những thứ mà khách hàng đang tìm kiếm mà chúng tôi không giải quyết ngay hôm nay, thì chúng tôi có thể tiếp tục và đưa ra những đề xuất đó”.

Việc chuyển đổi giữa giao tiếp với khách hàng và các nhóm kinh doanh kỹ thuật nội bộ đòi hỏi các kiến ​​trúc sư đám mây phải có kỹ năng giao tiếp mạnh mẽ. Vì kiến ​​trúc sư đám mây làm việc trên cơ sở hạ tầng kỹ thuật số cho phép một công ty hoạt động, họ có cơ hội tương tác và dẫn dắt các cuộc thảo luận kỹ thuật với nhiều đối tượng khác nhau như nhà phát triển, kỹ sư mạng, nhà quản lý, v.v.

Đối với Yahl, công việc cơ sở hạ tầng là thứ chi phối cuộc sống của cô gần đây. Tại Uncomn, cô ấy đã tìm hiểu khá nhiều về cơ sở hạ tầng mạng và cách triển khai nó. Nhưng rất nhiều việc cô ấy đang làm gần đây đặc biệt liên quan đến rất nhiều cơ sở hạ tầng dưới dạng mã. Điều này giúp tăng tính nhất quán trong toàn công ty và giảm cơ hội mắc lỗi của con người.

“Bạn muốn đảm bảo rằng nếu bạn cần tạo ra một ngăn xếp khác, một tập hợp máy chủ khác và tất cả những thứ đi kèm với nó, bạn muốn đảm bảo rằng bạn luôn làm theo cùng một cách,” cô nói.

Học tập là một phần của thói quen hàng ngày

Đó là kinh nghiệm phổ biến đối với các kiến ​​trúc sư đám mây.

Yahl nói: “Cánh đồng khác nhau mỗi ngày. “Đó là một trong những điều mà nếu bạn không phấn đấu học hỏi, thì bạn sẽ bị tụt lại phía sau”.

Dagenhardt cho biết tốc độ phát triển nhanh chóng của công nghệ đám mây là một trong những điều khiến anh ấy thức đêm. Ông chỉ ra rằng AWS đã mở rộng cung cấp của mình lên hơn 200 dịch vụ vào tháng 9. Và đó chỉ là một nhà cung cấp.

Luôn cập nhật các tùy chọn, cách khách hàng có thể tận dụng các công nghệ mới và các phương pháp hay nhất có thể giúp bảo mật chúng, tất cả đều yêu cầu học hỏi liên tục. Đối với Dagenhardt, việc duy trì các chứng chỉ và học hỏi những điều mới khiến anh ấy cảm thấy mình luôn đứng đầu cuộc chơi.

“Đó luôn là điều đã giúp ích cho tôi – dành một chút thời gian của tôi cho sự thăng tiến và cải thiện cá nhân,” anh nói.

Yahl cũng nói về tầm quan trọng của việc tiếp tục học tập và các chứng chỉ của bạn, nhưng cô ấy cũng nhấn mạnh giá trị của việc học hỏi từ những người bạn làm việc cùng.

“Các bạn học hỏi lẫn nhau, đặc biệt là các phím tắt hoặc công cụ giúp cuộc sống dễ dàng hơn,” cô nói, đồng thời đưa Visual Studio Code và ShellCheck làm ví dụ về các nguồn mà cô học được từ đồng nghiệp.

Nhưng cô ấy nói rằng không chỉ đơn thuần là chọn những công cụ hữu ích có thể giúp một ngày trở nên dễ dàng hơn. Ngoài ra còn có yếu tố hợp tác là có được những quan điểm khác nhau về cách sử dụng hoặc triển khai các công nghệ khác nhau.

“Khi bạn đang làm việc một mình, bạn đang ở trong khoảng trống và bạn không có ai để xem mã của mình, không ai để đảm bảo rằng bạn đang tuân thủ các phương pháp hay nhất tốt nhất có thể hoặc biết về những cách làm mới và đang phát triển Yahl nói.

Trong những tình huống mà một kiến ​​trúc sư đám mây có thể không có đồng nghiệp để học hỏi từ đó, Yahl đề xuất những địa điểm như Reddit, nơi những người khác trong cộng đồng công nghệ đến để đặt câu hỏi cho nhau về các tài nguyên tốt nhất cho các tình huống khác nhau.

“Về cơ bản, bạn có một danh sách những thứ mà mọi người sẽ giới thiệu và sau đó bạn nhận được quan điểm của người khác về những điều tốt và xấu về những công cụ đó và có một cuộc trò chuyện diễn ra liên tục,” cô nói. “Vì vậy, ngay cả khi bạn không có đồng nghiệp hướng dẫn, bạn vẫn có thể nhìn thấy nhiều quan điểm đó.”

Mối quan tâm về bảo mật trong lĩnh vực đa đám mây, phát triển nhanh

Hiểu và có thể làm việc trên nhiều nền tảng là nhu cầu ngày càng tăng đối với các kiến ​​trúc sư đám mây. Dagenhardt khuyên những người sẽ là kiến ​​trúc sư đám mây nên có sự kết hợp giữa các quan điểm khi nói đến nền tảng đám mây vì đó là nơi anh ấy nhìn thấy tương lai của lĩnh vực này.

“Những gì chúng tôi đã thấy trong ngành công nghiệp đám mây là, trong khi hầu hết khách hàng bắt đầu từ một nhà cung cấp đám mây duy nhất, theo thời gian, họ trở thành một môi trường đa đám mây, nơi họ lưu trữ một số tài nguyên của mình trong một hoặc nhiều đám mây,” ông nói. Ông cũng nói rằng ông đang thấy sự thay đổi ngày càng tăng từ cơ sở hạ tầng như một dịch vụ sang các thùng chứa hoặc thậm chí là các công nghệ không máy chủ.

Theo Tedrick, xu hướng đa dạng hóa đám mây này, các chiến lược và các yếu tố dựa trên đám mây khác như “cuộc chiến điện toán đám mây lớn hơn giữa AWS, Google và Microsoft” sẽ khiến vai trò kiến ​​trúc sư đám mây trở nên thịnh hành. Điều này có nghĩa là các nhà tuyển dụng đang tìm kiếm kiến ​​trúc sư đám mây sẽ muốn biết các kiến ​​trúc sư có kinh nghiệm thực hành về nền tảng đám mây nào.

Bảo mật trong môi trường ngày càng mở rộng và không có kỹ thuật này đang và sẽ tiếp tục là mối quan tâm của những người làm việc với đám mây.

Yahl nói: “Chúng tôi sẽ có những tính toán trong thế giới an ninh, đó là điều chắc chắn. “Có rất nhiều người muốn tham gia vào lĩnh vực này và họ học những kiến ​​thức cơ bản của họ, nhưng họ không học được sự bảo mật đằng sau nó.”

Điều này một phần là do tốc độ của trường đám mây vượt xa khả năng của hầu hết các nền giáo dục chính quy trong việc cập nhật đào tạo về bảo mật, nhưng cũng bởi vì đám mây, theo Yahl, “rào cản gia nhập thấp nhất đối với bất kỳ ai cần thiết lập cơ sở hạ tầng của họ. ”

Bà nói: “Đám mây rất tuyệt vời để quay các máy chủ và cơ sở hạ tầng và tất cả điều đó thực sự, rất nhanh chóng và thực sự dễ dàng,” cô nói, đồng thời cho biết thêm rằng nhiều giá trị mặc định trong môi trường đám mây có thể không an toàn. “Đám mây là một cách để thiết lập và chạy rất nhanh nhưng bạn cũng phải bảo mật nó.”

Tốc độ tiến bộ của công nghệ đám mây cũng khiến Dagenhardt đặt ra các câu hỏi bảo mật về tương lai.

Ông nói: “Chúng tôi vẫn có công nghệ cũ hơn và kế thừa hơn mà chúng tôi phải có khả năng xử lý và thích ứng. “Làm cách nào để chúng ta bảo vệ môi trường truyền thống cũng như bảo vệ môi trường đám mây và đảm bảo rằng nó có thể quản lý được và không tạo ra gấp đôi công việc cho khách hàng?”

Làm thế nào để trở thành một kiến trúc sư đám mây

Nếu không ngừng học hỏi và thích ứng với nhu cầu thay đổi của khách hàng và cảnh quan đám mây đang phát triển nghe có vẻ hấp dẫn, thì có một số lời khuyên cần ghi nhớ. Tedrick cho biết: Đứng đầu trong số đó là các kiến ​​trúc sư đám mây phải biết và hiểu rõ về điện toán đám mây ngoài những điều cơ bản.

“Họ sẽ cần hiểu các phương pháp hay nhất về bảo mật đám mây doanh nghiệp, quản trị, tối ưu hóa chi phí, kiến ​​trúc đám mây kết hợp – sử dụng môi trường đám mây và tại chỗ – và kiến ​​trúc đa đám mây – sử dụng hai hoặc nhiều đám mây”, cô nói. “Trải nghiệm thực tế trên nền tảng đám mây nơi họ đang tạo và giám sát tài nguyên là điều bắt buộc, ưu tiên một năm kinh nghiệm trở lên.”

Đối với những người không có cơ hội làm việc trên đám mây tại chỗ, Tedrick đã đề xuất các nền tảng bài học trực tuyến như A Cloud Guru và Pluralsight để cung cấp cho người dùng trải nghiệm thực tế với các nền tảng đám mây khác nhau.

Khi đề cập đến việc ứng tuyển vai trò kiến ​​trúc sư đám mây, Yahl cho biết những người tìm việc không nên nản lòng nếu một bài đăng bao gồm các yêu cầu bạn không có hoặc liên quan đến các nhiệm vụ bạn không quen thuộc. Cô cũng chỉ ra rằng các tin tuyển dụng đôi khi không được viết bởi các chuyên gia kỹ thuật và yêu cầu những điều không thể. Đây có thể là một cái gì đó giống như yêu cầu nhiều năm kinh nghiệm trong một sản phẩm hơn nó đã tồn tại.

“Nếu bạn đang muốn dấn thân vào lĩnh vực này, đừng để điều gì khiến bạn sợ hãi về vị trí mà bạn có hầu hết các kỹ năng,” cô khuyên.

Yahl cũng khuyến khích những người muốn tham gia vào lĩnh vực kiến ​​trúc đám mây để thể hiện kỹ năng của họ và thực tế là họ đã phát triển và thay đổi trong những năm qua. Cô ấy chỉ ra Github hoặc các nền tảng khác nơi người dùng có thể lưu trữ mã là những nơi tuyệt vời để tạo danh mục đầu tư mã hóa.

Chứng chỉ rất quan trọng đối với các kiến ​​trúc sư đám mây tiềm năng. Đây có thể là nhà cung cấp cụ thể và nhà cung cấp bất khả tri. Các chứng nhận tổng quát hơn có thể hữu ích cho thông tin chung và các phương pháp hay nhất về đám mây, nhưng theo Dagenhardt, các chứng chỉ dành riêng cho nhà cung cấp thường hữu ích hơn vì chúng sẽ giải quyết các sản phẩm đám mây cụ thể và các phương pháp hay nhất của chúng.

Tedrick cũng chỉ ra rằng các chứng chỉ của các nhà cung cấp chính – Microsoft, AWS, Google và IBM – có nhiều khả năng được các nhà tuyển dụng tiềm năng công nhận hơn.

Nhưng cô ấy nhấn mạnh rằng “mục tiêu phải là đạt được kỹ năng và kinh nghiệm thay vì đạt được chứng chỉ, vì chứng chỉ sẽ chỉ giúp bạn có được cho đến nay, và các kiến ​​trúc sư vĩ đại được sinh ra từ thử thách, sai lầm và thời gian.”

Cảm ơn mọi người đã theo dõi. Author: DuongVT19.

Container

Một trong những Widget được sử dụng nhiều nhất – và vì những lý do này:

Container as a layout tool

Khi bạn không chỉ định height và width của Container, nó sẽ khớp với child kích thước của nó

Widget build(BuildContext context) {
  return Scaffold(
    appBar: AppBar(title: Text('Container as a layout')),
    body: Container(
      color: Colors.yellowAccent,
      child: Text("Hi"),
    ),
  );
}

Nếu bạn muốn kéo dài Container để khớp với cha của nó, hãy sử dụng double.infinity cho các thuộc tính height và width

Widget build(BuildContext context) {
  return Scaffold(
    appBar: AppBar(title: Text('Container as a layout')),
    body: Container(
      height: double.infinity,
      width: double.infinity,
      color: Colors.yellowAccent,
      child: Text("Hi"),
    ),
  );
}

Container as decoration

Bạn có thể sử dụng thuộc tính color để làm thay đổi màu nền của Container bằng decoration và foregroundDecoration.

Widget build(BuildContext context) {
  return Scaffold(
    appBar: AppBar(title: Text('Container.decoration')),
    body: Container(
      height: double.infinity,
      width: double.infinity,
      decoration: BoxDecoration(color: Colors.yellowAccent),
      child: Text("Hi"),
    ),
  );
}

. . .

Widget build(BuildContext context) {
  return Scaffold(
    appBar: AppBar(title: Text('Container.foregroundDecoration')),
    body: Container(
      height: double.infinity,
      width: double.infinity,
      decoration: BoxDecoration(color: Colors.yellowAccent),
      foregroundDecoration: BoxDecoration(
        color: Colors.red.withOpacity(0.5),
      ),
      child: Text("Hi"),
    ),
  );
}

Container as Transform

Nếu bạn không muốn sử dụng widget Transform để thay đổi bố cục của mình, bạn có thể sử dụng transform thuộc tính từ Container

Widget build(BuildContext context) {
  return Scaffold(
    appBar: AppBar(title: Text('Container.transform')),
    body: Container(
      height: 300,
      width: 300,
      transform: Matrix4.rotationZ(pi / 4),
      decoration: BoxDecoration(color: Colors.yellowAccent),
      child: Text(
        "Hi",
        textAlign: TextAlign.center,
      ),
    ),
  );
}

. . .

BoxDecoration

BoxDecoration thường được sử dụng trên tiện ích Container để thay đổi diện mạo của Container.

image: DecorationImage

Đặt một hình ảnh làm nền:

Scaffold(
  appBar: AppBar(title: Text('image: DecorationImage')),
  body: Center(
    child: Container(
      height: 200,
      width: 200,
      decoration: BoxDecoration(
        color: Colors.yellow,
        image: DecorationImage(
          fit: BoxFit.fitWidth,
          image: NetworkImage(
            'https://flutter.io/images/catalog-widget-placeholder.png',
          ),
        ),
      ),
    ),
  ),
);

border: Border

Chỉ định đường viền của Container sẽ trông như thế nào.

Scaffold(
  appBar: AppBar(title: Text('border: Border')),
  body: Center(
    child: Container(
      height: 200,
      width: 200,
      decoration: BoxDecoration(
        color: Colors.yellow,
        border: Border.all(color: Colors.black, width: 3),
      ),
    ),
  ),
);

borderRadius: BorderRadius

Cho phép làm tròn các góc của đường viền.

borderRadius không hoạt động nếu shape trong decoration là BoxShape.circle

Scaffold(
  appBar: AppBar(title: Text('borderRadius: BorderRadius')),
  body: Center(
    child: Container(
      height: 200,
      width: 200,
      decoration: BoxDecoration(
        color: Colors.yellow,
        border: Border.all(color: Colors.black, width: 3),
        borderRadius: BorderRadius.all(Radius.circular(18)),
      ),
    ),
  ),
);

shape: BoxShape

BoxDecoration có thể là hình chữ nhật / hình vuông hoặc hình elip / hình tròn.

Đối với bất kỳ hình dạng nào khác, bạn có thể sử dụng ShapeDecoration thay thế cho BoxDecoration

Scaffold(
  appBar: AppBar(title: Text('shape: BoxShape')),
  body: Center(
    child: Container(
      height: 200,
      width: 200,
      decoration: BoxDecoration(
        color: Colors.yellow,
        shape: BoxShape.circle,
      ),
    ),
  ),
);

boxShadow: List<BoxShadow>

Thêm bóng vào Container .

Tham số này là một danh sách vì bạn có thể chỉ định nhiều bóng khác nhau và hợp nhất chúng lại với nhau.

Scaffold(
  appBar: AppBar(title: Text('boxShadow: List<BoxShadow>')),
  body: Center(
    child: Container(
      height: 200,
      width: 200,
      decoration: BoxDecoration(
        color: Colors.yellow,
        boxShadow: const [
          BoxShadow(blurRadius: 10),
        ],
      ),
    ),
  ),
);

gradient

Có ba loại gradient LinearGradient:, RadialGradientvà SweepGradient.

Scaffold(
  appBar: AppBar(title: Text('gradient: LinearGradient')),
  body: Center(
    child: Container(
      height: 200,
      width: 200,
      decoration: BoxDecoration(
        gradient: LinearGradient(
          colors: const [
            Colors.red,
            Colors.blue,
          ],
        ),
      ),
    ),
  ),
);

. . .

Scaffold(
  appBar: AppBar(title: Text('gradient: RadialGradient')),
  body: Center(
    child: Container(
      height: 200,
      width: 200,
      decoration: BoxDecoration(
        gradient: RadialGradient(
          colors: const [Colors.yellow, Colors.blue],
          stops: const [0.4, 1.0],
        ),
      ),
    ),
  ),
);

. . .

Scaffold(
  appBar: AppBar(title: Text('gradient: SweepGradient')),
  body: Center(
    child: Container(
      height: 200,
      width: 200,
      decoration: BoxDecoration(
        gradient: SweepGradient(
          colors: const [
            Colors.blue,
            Colors.green,
            Colors.yellow,
            Colors.red,
            Colors.blue,
          ],
          stops: const [0.0, 0.25, 0.5, 0.75, 1.0],
        ),
      ),
    ),
  ),
);

backgroundBlendMode

backgroundBlendMode là tài sản phức tạp nhất của BoxDecoration.
Nó chịu trách nhiệm trộn các màu / độ chuyển màu với nhau BoxDecorationvà bất cứ thứ gì BoxDecorationở trên cùng.

Với backgroundBlendModebạn có thể sử dụng một danh sách dài các thuật toán được chỉ định trong BlendModeenum.

Đầu tiên, hãy đặt BoxDecoration là foregroundDecoration

Scaffold(
  appBar: AppBar(title: Text('backgroundBlendMode')),
  body: Center(
    child: Container(
      height: 200,
      width: 200,
      foregroundDecoration: BoxDecoration(
        backgroundBlendMode: BlendMode.exclusion,
        gradient: LinearGradient(
          colors: const [
            Colors.red,
            Colors.blue,
          ],
        ),
      ),
      child: Image.network(
        'https://flutter.io/images/catalog-widget-placeholder.png',
      ),
    ),
  ),
);

. . .

Material

Đường viền với các góc cắt

Scaffold(
  appBar: AppBar(title: Text('shape: BeveledRectangleBorder')),
  body: Center(
    child: Material(
      shape: const BeveledRectangleBorder(
        borderRadius: BorderRadius.all(Radius.circular(20)),
        side: BorderSide(color: Colors.black, width: 4),
      ),
      color: Colors.yellow,
      child: Container(
        height: 200,
        width: 200,
      ),
    ),
  ),
);

. . .

Slivers

SliverFillRemaining

Widget này không thể thay thế khi bạn muốn căn giữa nội dung của mình ngay cả khi không có đủ dung lượng cho nó. Ví dụ

Scaffold(
  appBar: AppBar(title: Text('SliverFillRemaining')),
  body: CustomScrollView(
    slivers: [
      SliverFillRemaining(
        hasScrollBody: false,
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: const [
            FlutterLogo(size: 200),
            Text(
              'This is some longest text that should be centered'
              'together with the logo',
              textAlign: TextAlign.center,
            ),
          ],
        ),
      ),
    ],
  ),
);

Trong trường hợp không có đủ không gian cho nội dung được căn giữa, nội dung SliverFillRemaining sẽ có thể cuộn được:

Nếu không có SliverFillRemaining nội dung sẽ tràn như thế này:

Làm đầy không gian còn lại

Ngoài việc hữu ích cho việc căn giữa nội dung của bạn, SliverFillRemaining nó sẽ lấp đầy không gian trống còn lại của khung nhìn. Để làm được điều đó, widget này phải được đặt vào CustomScrollView và cần phải là mảnh cuối cùng

Trong trường hợp không có đủ dung lượng, tiện ích con sẽ có thể cuộn được:

Scaffold(
  appBar: AppBar(title: Text('SliverFillRemaining')),
  body: CustomScrollView(
    slivers: [
      SliverList(
        delegate: SliverChildListDelegate(const [
          ListTile(title: Text('First item')),
          ListTile(title: Text('Second item')),
          ListTile(title: Text('Third item')),
          ListTile(title: Text('Fourth item')),
        ]),
      ),
      SliverFillRemaining(
        hasScrollBody: false,
        child: Container(
          color: Colors.yellowAccent,
          child: Column(
            mainAxisAlignment: MainAxisAlignment.center,
            children: const [
              FlutterLogo(size: 200),
              Text(
                'This is some longest text that should be centered'
                'together with the logo',
                textAlign: TextAlign.center,
              ),
            ],
          ),
        ),
      ),
    ],
  ),
);

. . .

SizedBox

Đây là một trong những Widget đơn giản nhưng hữu ích nhất

SizedBox dưới dạng ConstrainedBox

SizedBox có thể hoạt động theo cách tương tự như ConstrainedBox

SizedBox.expand(
  child: Card(
    child: Text('Hello World!'),
    color: Colors.yellowAccent,
  ),
),

. . .

SizedBox dưới dạng padding

Khi cần thêm phần đệm hoặc lề, bạn có thể chọn Padding hoặc Container các widget. Nhưng chúng có thể dài dòng hơn và khó đọc hơn so với việc thêm một Sizedbox

Column(
  children: <Widget>[
    Icon(Icons.star, size: 50),
    const SizedBox(height: 100),
    Icon(Icons.star, size: 50),
    Icon(Icons.star, size: 50),
  ],
),

SizedBox như một đối tượng vô hình

Nhiều khi bạn muốn ẩn / hiện một tiện ích phụ thuộc vào bool

• 

• 

Widget build(BuildContext context) {
  bool isVisible = ...
  return Scaffold(
    appBar: AppBar(
      title: Text('isVisible = $isVisible'),
    ),
    body: isVisible 
      ? Icon(Icons.star, size: 150) 
      : const SizedBox(),
  );
}

Vì SizedBox có một hàm const tạo nên việc sử dụng const SizedBox()thực sự rất tối ưu**.

** Một giải pháp tối ưu hơn sẽ là sử dụng Opacity widget và thay đổi opacity giá trị thành 0.0. Hạn chế của giải pháp này là tiện ích đã cho sẽ chỉ ẩn, vẫn chiếm không gian.

. . .

Trên các nền tảng khác nhau, có những khu vực đặc biệt như Thanh trạng thái trên Android hoặc Notch trên iPhone X mà chúng tôi có thể tránh vẽ dưới.

Giải pháp cho vấn đề này là SafeArea widget (ví dụ không có / có SafeArea)

• 

• 

Widget build(BuildContext context) {
  return Material(
    color: Colors.blue,
    child: SafeArea(
      child: SizedBox.expand(
        child: Card(color: Colors.yellowAccent),
      ),
    ),
  );
}

Kết thúc phần 3!

FaunaDB là một lớp khác biệt với hầu hết các cơ sở dữ liệu xung quanh. Nó cung cấp tính linh hoạt và khả năng mở rộng đáng kinh ngạc. Vì FaunaDB không có máy chủ nên bạn có thể kết nối với cơ sở dữ liệu và sử dụng nó mà không cần lo lắng về bất kỳ điều gì khác.

Bạn có thể sử dụng FaunaDB làm cơ sở dữ liệu OLTP (xử lý giao dịch trực tuyến) với ACID phân tán (tính nguyên tử, tính nhất quán, tính cách ly, độ bền), làm cơ sở dữ liệu tài liệu hoặc thậm chí là NoSQL dựa trên khóa-giá trị đơn giản. Nó cũng bao gồm hỗ trợ cho các tính năng doanh nghiệp như lưu giữ dữ liệu có thể định cấu hình và cho thuê nhiều lần theo thứ bậc.

Quan trọng là, FaunaDB không ràng buộc bạn với đám mây. Nó có sẵn dưới dạng dịch vụ đám mây được quản lý hoặc JAR có thể tải xuống, hình ảnh máy hoặc vùng chứa mà bạn có thể chạy tại chỗ.

Chức năng của FaunaDB

FaunaDB cung cấp tính linh hoạt cao, cho phép bạn tinh chỉnh một số thông số dựa trên các yêu cầu của dự án của bạn. Chúng ta có thể sử dụng FaunaDB làm cơ sở dữ liệu quan hệ truyền thống, cơ sở dữ liệu khóa-giá trị, dựa trên tài liệu hoặc đồ thị. Chúng ta có thể thực thi một lược đồ trên dữ liệu hoặc chỉ để nó lỏng lẻo.

FaunaDB là cực kỳ linh hoạt. Chúng ta có thể chạy FaunaDB trên đám mây (dưới dạng cơ sở dữ liệu không máy chủ với cấp miễn phí phong phú), tại cơ sở hoặc dưới dạng cơ sở dữ liệu nhúng, ngay bên trong ứng dụng của chúng ta. Cùng với những điểm cực đoan này, nó cũng cung cấp các hình thức triển khai phổ biến nhất như hình ảnh máy và hình ảnh docker.

Tất cả điều này đi kèm với các giao dịch ACID và hiệu suất rất cao – mọi thứ mà một kiến trúc sư muốn cho một ứng dụng.

Fauna Console

Mặc dù Fauna cung cấp một trình bao lệnh thanh lịch cho đám mây DB (cơ sở dữ liệu), chúng ta hãy bắt đầu với bảng điều khiển web, đây là cách dễ dàng nhất để tham gia.

Sau khi đăng ký, bạn sẽ thấy trang tổng quan giống như sau:

Tạo cơ sở dữ liệu

Để tạo cơ sở dữ liệu, bạn sẽ bắt đầu bằng cách nhấp vào Cơ sở dữ liệu mới (khá trực quan!). Sau khi bạn cung cấp tên DB, bạn đã hoàn tất; bây giờ bạn có một phiên bản DB mới cho ứng dụng của bạn. Nếu bạn chỉ muốn thực hành, bạn có thể chọn tùy chọn điền dữ liệu giả vào DB hoặc bạn có thể thêm dữ liệu của riêng mình.

Với điều đó, bạn có một phiên bản cơ sở dữ liệu sạch.

Tạo Collection.

Tất nhiên, bước tiếp theo là tạo một bộ sưu tập. Fauna cung cấp một số lựa chọn khi chúng ta tạo một collection mới.

Trang tạo collection trông giống như sau:

Cùng với tên bộ sưu tập, chúng ta có hai tùy chọn. Ngày lịch sử và TTL (Thời gian tồn tại) cho mỗi bản ghi. Ngày lịch sử là số ngày Fauna sẽ lưu lại lịch sử của tài liệu (trong trường hợp bạn muốn hoàn tác thay đổi). Nếu chúng ta dọn sạch lĩnh vực này, lịch sử sẽ được lưu giữ mãi mãi. Đương nhiên, dữ liệu lịch sử cũng là dữ liệu được tính phí trên đám mây, vì vậy bạn phải cẩn thận khi chọn số này.

TTL xác định số ngày mà một tài liệu chưa được chỉnh sửa ở lại trong bộ sưu tập sau lần viết cuối cùng. Việc đặt giá trị hợp lý cho TTL khá hữu ích vì nó có thể giúp giảm chi phí.

Cuối cùng, chúng ta nhấn lưu và – bùng nổ – bạn đã tạo một bộ sưu tập mới. Bây giờ bạn sẽ thấy một giao diện người dùng sạch để thêm tài liệu mới vào bộ sưu tập.

Tạo Document

Nhấp vào nút đó sẽ hiển thị cho chúng ta một hộp văn bản nơi chúng ta có thể nhập JSON cho tài liệu mới mà chúng ta muốn thêm vào bộ sưu tập của mình.

Bảng điều khiển cũng cung cấp một số tùy chọn khác để tạo chỉ mục, chức năng tùy chỉnh, thêm lược đồ GraphQL và cũng để tạo khóa bảo mật để truy cập cơ sở dữ liệu.

Nếu bạn cảm thấy nhàm chán với giao diện người dùng, bảng điều khiển sẽ cung cấp liên kết để mở giao diện người dùng. Tại đây, chúng ta có thể gõ các lệnh cần thiết để làm việc với cơ sở dữ liệu. Trên thực tế, Fauna cũng cho phép chúng ta mở một trình bao trên thiết bị đầu cuối cục bộ của chúng ta để có thể tương tác với cơ sở dữ liệu. Hãy cùng kiểm tra nào.

Fauna Shell

Bất kỳ ai nghiêm túc về việc xây dựng các ứng dụng trong thế giới thực đều nên bỏ bảng điều khiển web và quay lại màn hình đen. Đó là cách tốt nhất để phát triển. Fauna cung cấp một CLI (giao diện dòng lệnh) rất tốt và một shell dựa trên NodeJS để giao tiếp với ứng dụng trên đám mây.

Hãy bắt đầu với việc cài đặt. Nếu bạn đã hiểu được điều này, ta khá chắc chắn rằng bạn biết cách cài đặt NodeJS và npm (nếu chúng chưa được cài đặt). Vì vậy, hãy bắt đầu sau thời điểm đó. Chúng ta phải cài đặt Fauna shell bằng npm.

 Npm tập hợp tất cả những gì bạn cần để chạy Fauna shell và thiết lập nó.

Tiếp theo, chúng ta đăng nhập vào tài khoản đám mây Fauna của mình.

Điều này yêu cầu email và mật khẩu mà chúng ta đã sử dụng để đăng ký. Nó cũng có một tùy chọn để đăng nhập bằng một chìa khóa.

QUERY DOCUMENTS

Bây giờ, hãy thử tìm nạp các bản ghi từ bộ sưu tập. Có hai cách để truy vấn dữ liệu này. Bạn có thể sử dụng ID hoặc chỉ mục.

Lưu ý trong các hoạt động tạo ở trên, chúng ta có một số – 270925464408687111 – trong xác nhận. Bạn có thể sử dụng điều này để truy vấn bản ghi.

Điều này trả về bản ghi mà chúng ta vừa chèn.

Tất nhiên, đây là một cách nhàm chán để truy vấn dữ liệu. Tại sao chúng ta tạo chỉ mục? Hãy sử dụng chỉ mục đó để truy vấn bản ghi được yêu cầu.

Chúng ta có thể truy vấn cùng một bản ghi bằng cách sử dụng chỉ mục trên tiêu đề mà chúng ta đã tạo ở trên.

Nó trả về cùng một bản ghi.

Đó chỉ là một cái nhìn thoáng qua về những gì chúng ta có thể làm với bảng điều khiển web và shell. Fauna có tài liệu rất tốt. Bạn có thể xem Sách dạy nấu ăn trên trang web của họ để có một bộ sưu tập tốt các đoạn mã cho các trường hợp sử dụng khác nhau.

Cảm ơn mọi người đã theo dõi.

Author: DuongVT19

Quy trình phát triển phần mềm Scrum

Scrum là một quy trình thực hiện hóa những giá trị và nguyên tắc của Agile

1. Tổng quan về Scrum

• Có một quy trình phát triển phần mềm truyền thống có tên là waterfall (mô hình thác nước)

Quy trình này kéo dài từ đầu đến cuối trong quá trình phát triển phần mềm, và khách hàng sẽ phải chờ đợi đến phần cuối cùng của quy trình này để có thể nhìn thấy được sản phẩm của cả quá trình phát triển. Điều này là khá thụ động cho cả bên phía khách hàng và cho cả bên phát triển phần mềm.

Minh chứng là khi tiếp nhận những sự thay đổi tại thời điểm cuối của quy trình sẽ có thể phải đập đi xây lại rất nhiều phần gây mất thêm thời gian maintain.

Từ đó chúng ta mong muốn tạo ra một dự án “Deliverable Product” hay chính là sử dụng quy trình Scrum.

• Chúng ta chia nhỏ dự án thành các Sprint (mỗi Sprint kéo dài trong vòng 1 đến 3 tuần)
• Và cuối mỗi Sprint này chúng ta sẽ có một bản release, một bản chạy được để đưa cho khách hàng (dù nó chỉ là một chức năng nhỏ đã được hoàn thiện)
• VD: Giả sự một phần mềm được phát triển trong vòng 6 tháng thì tương ứng sẽ có khoảng 24 Sprint và cùng với đó là 24 bản release để đưa cho khách hàng. Con số này lớn hơn rất nhiều so với mô hình waterfall
• Việc đưa ra các bản release liên tục này sẽ giúp cho khách hàng có được cái nhìn tổng quan, khách quan hơn về sản phẩm đang được phát triển, đưa ra các feedback cho đội ngũ phát triển

2. Ba Roles trong Scrum

• Product Owner: Tập hợp tất cả yêu cầu khách hàng yêu cầu dự án phân chia các task theo thứ tự ưu tiên rồi giao cho đội ngũ phát triển.
• Scrum Master: Giúp cho team làm việc tốt nhất, đảm bảo team đi đúng theo mô hình, quy trình đã đề ra.
• Team: Gồm Dev, Tester, Content, …

3. Ba Artifact trong Scrum

• Product Backlog: Tất cả các task cần làm, các thông tin Product Owner lấy được từ khách hàng.
• Sprint Backlog: Chứa các user story trong một Sprint, đã được chọn để làm trong Sprint
• Burndown Chart: Chứa các task bạn làm trong một Sprint, đánh giá hiệu quả của Sprint

User Story: là một đặc tả một task dựa trên vị trí người dùng, nó mô tả những việc người dùng cần thao tác để đạt được điều mong muốn

4. Ba Meeting trong Scrum

• Sprint Planing: Bàn bạc về các task sẽ bỏ vào trong Sprint Backlog, dự đoán số điểm cho các User Story. Được tổ chức trước khi làm một Sprint.
• Daily Scrum: Đồng bộ các tin tức, thông tin giữa mọi người trong dự án với nhau, đưa ra các vấn đề, trạng thái của task.
• Sprint Review/Sprint Retrospective: Demo các task đã hoàn thành trong Sprint. Tìm ra những điểm đã làm tốt để phát huy và hạn chế những điểm chưa tốt.

Quy trình chuẩn của một Sprint

5. Điểm lợi của Scrum

• Luôn mang lại giá trị cao nhất cho người đầu tư dự án.
• Năng suất lao động rất cao.

Tài liệu tham khảo: Scrum cơ bản | Quy trình phát triển phần mềm | Ong Dev – YouTube

Author: LamNT59

Tổng quan:

Mô hình Waterfall là mô hình vòng đời tuần tự tuyến tính. Nó rất đơn giản để hiểu và sử dụng. Trong mô hình Waterfall, mỗi giai đoạn phải được hoàn thành trước khi giai đoạn tiếp theo có thể bắt đầu và không có sự chồng chéo trong các giai đoạn.

Mô hình Waterfall là cách tiếp cận SDLC (chu trình phát triền phần mêm) sớm nhất được sử dụng để phát triển phần mềm.

Mô hình Waterfall minh họa quá trình phát triển phần mềm theo một dòng tuần tự tuyến tính. Điều này có nghĩa là bất kỳ giai đoạn nào trong quá trình phát triển chỉ bắt đầu nếu giai đoạn trước đó hoàn thành. Trong mô hình Waterfall này, các pha không chồng lên nhau.

Thiết kế Waterfall Model

Phương pháp tiếp cận mô hình Waterfall là Mô hình SDLC đầu tiên được sử dụng rộng rãi trong kỹ thuật phần mềm để đảm bảo sự thành công của dự án. Trong cách tiếp cận “The Waterfall”, toàn bộ quá trình phát triển phần mềm được chia thành các giai đoạn riêng biệt. Trong mô hình Waterfall này, thông thường, kết quả của một giai đoạn đóng vai trò là đầu vào cho giai đoạn tiếp theo một cách tuần tự.

Hình minh họa sau đây là đại diện cho các giai đoạn khác nhau của Mô hình Waterfall.

Các giai đoạn tuần tự trong mô hình Waterfall là:

• Thu thập và phân tích yêu cầu (Requirement Gathering and analysis): Tất cả các yêu cầu có thể có của hệ thống được phát triển đều được ghi lại trong giai đoạn này và được ghi lại trong tài liệu đặc tả yêu cầu.
• Thiết kế hệ thống (System Design): Các thông số kỹ thuật yêu cầu từ giai đoạn đầu tiên được nghiên cứu trong giai đoạn này và thiết kế hệ thống đã được chuẩn bị. Thiết kế hệ thống này giúp xác định các yêu cầu phần cứng và hệ thống cũng như giúp xác định kiến trúc hệ thống tổng thể.
• Thực hiện (Implementation): Với đầu vào từ thiết kế hệ thống, hệ thống được phát triển đầu tiên trong các chương trình nhỏ được gọi là các đơn vị, được tích hợp trong giai đoạn tiếp theo. Mỗi đơn vị được phát triển và kiểm tra chức năng của nó, được gọi là Kiểm thử đơn vị (Unit test).
• Tích hợp và Kiểm tra (Integration and Testing) Tất cả các đơn vị được phát triển trong giai đoạn triển khai được tích hợp vào một hệ thống sau khi thử nghiệm của từng đơn vị. Sau khi tích hợp, toàn bộ hệ thống được kiểm tra xem có bất kỳ lỗi và hỏng hóc nào không.
• Triển khai hệ thống (Deployment of system) Sau khi kiểm tra chức năng và phi chức năng được thực hiện; sản phẩm được triển khai trong môi trường khách hàng hoặc được tung ra thị trường.
• Bảo trì (Maintenance) Có một số vấn đề xảy ra trong môi trường khách hàng. Để khắc phục những vấn đề đó, các bản vá được phát hành. Ngoài ra để nâng cao sản phẩm một số phiên bản tốt hơn được phát hành. Bảo trì được thực hiện để mang lại những thay đổi này trong môi trường khách hàng.

Tất cả các giai đoạn này được xếp tầng với nhau, trong đó tiến trình được xem như chảy đều đặn xuống dưới (giống như Waterfall) qua các giai đoạn. Giai đoạn tiếp theo chỉ được bắt đầu sau khi đạt được tập hợp mục tiêu đã xác định cho giai đoạn trước và nó được ký kết, vì vậy có tên “Mô hình Waterfall”. Trong mô hình này, các giai đoạn không chồng chéo lên nhau.

Ứng dụng mô hình Waterfall.

Mỗi phần mềm được phát triển đều khác nhau và đòi hỏi phải tuân theo một cách tiếp cận SDLC phù hợp dựa trên các yếu tố bên trong và bên ngoài. Một số tình huống mà việc sử dụng mô hình Waterfall là thích hợp nhất:

• Các yêu cầu được ghi chép rất đầy đủ, rõ ràng và cố định.
• Định nghĩa sản phẩm là ổn định.
• Công nghệ được hiểu và không phải là năng động.
• Không có yêu cầu mơ hồ.
• Có sẵn các nguồn lực dồi dào với kiến thức chuyên môn cần thiết để hỗ trợ sản phẩm.
• Dự án ngắn hạn.

Ưu điểm của mô hình Waterfall.

Ưu điểm của phát triển mô hình Waterfall là nó cho phép phân thành các phần và dễ dàng kiểm soát. Một lịch trình có thể được thiết lập với thời hạn cho từng giai đoạn phát triển và một sản phẩm có thể tiến hành từng giai đoạn của mô hình quy trình phát triển.

Sự phát triển di chuyển từ khái niệm, thông qua thiết kế, thực hiện, thử nghiệm, cài đặt, khắc phục sự cố và kết thúc ở vận hành và bảo trì. Mỗi giai đoạn phát triển diễn ra theo thứ tự nghiêm ngặt.

Một số ưu điểm chính của Mô hình Waterfall như sau:

• Đơn giản và dễ để hiểu và sử dụng
• Dễ dàng quản lý do độ cứng của mô hình. Mỗi giai đoạn có các phân phối cụ thể và một quy trình xem xét.
• Các giai đoạn được xử lý và hoàn thành cùng một lúc.
• Hoạt động tốt cho các dự án nhỏ hơn, nơi các yêu cầu được hiểu rất rõ.
• Các giai đoạn được xác định rõ ràng.
• Các mốc quan trọng được hiểu rõ.
• Dễ dàng sắp xếp các công việc.
• Quá trình và kết quả được ghi lại đầy đủ.

Nhược điểm của mô hình Waterfall.

Nhược điểm của phát triển Waterfall là nó không cho phép phản ánh hoặc sửa đổi nhiều. Một khi ứng dụng đang trong giai đoạn thử nghiệm, rất khó để quay lại và thay đổi điều gì đó không được ghi chép đầy đủ hoặc được nghĩ đến trong giai đoạn khái niệm.

Những nhược điểm chính của Mô hình Waterfall như sau:

• Không có phần mềm đang hoạt động nào được sản xuất cho đến cuối vòng đời.
• Lượng rủi ro cao và không chắc chắn.
• Không phải là một mô hình tốt cho các dự án hướng đối tượng và phức tạp.
• Mô hình kém cho các dự án dài và đang diễn ra.
• Không phù hợp với các dự án mà các yêu cầu có nguy cơ thay đổi từ trung bình đến cao. Vì vậy, rủi ro và sự không chắc chắn là cao với mô hình quy trình này.
• Rất khó để đo lường sự tiến bộ trong các giai đoạn.
• Không thể đáp ứng các yêu cầu thay đổi.
• Điều chỉnh phạm vi trong vòng đời có thể kết thúc một dự án.
• Việc tích hợp được thực hiện như một “vụ nổ lớn ở giai đoạn cuối, điều này không cho phép xác định sớm bất kỳ điểm nghẽn hoặc thách thức nào về công nghệ hoặc kinh doanh.

Cảm ơn mọi người đã theo dõi.

Author: DuongVT19