Tích hợp liên tục - Giảm rủi ro
Có khả năng mọi thứ sẽ không thành công trong một dự án. Bằng cách thực hành CI một cách hiệu quả, bạn sẽ tìm ra điều gì sẽ xảy ra ở mọi bước trên đường đi, thay vì sau đó khi dự án đang trong chu kỳ phát triển. CI giúp bạn xác định và giảm thiểu rủi ro khi chúng xảy ra, giúp bạn dễ dàng đánh giá và báo cáo tình hình hoạt động của dự án dựa trên bằng chứng cụ thể.
Phần này sẽ tập trung vào những rủi ro có thể tránh được bằng cách sử dụng Tích hợp liên tục.
Trong bất kỳ dự án nào, có rất nhiều rủi ro cần được quản lý. Bằng cách loại bỏ các rủi ro sớm hơn trong vòng đời phát triển, sẽ có ít khả năng những rủi ro này phát triển thành các vấn đề sau này, khi hệ thống thực sự hoạt động.
Rủi ro 1 - Thiếu phần mềm có thể triển khai
“It works on my machine but does not work on another”- Đây có lẽ là một trong những cụm từ phổ biến nhất gặp phải trong bất kỳ tổ chức phần mềm nào. Do số lượng thay đổi được thực hiện đối với các bản xây dựng phần mềm hàng ngày, nên đôi khi có rất ít sự tin tưởng về việc liệu bản dựng của phần mềm có thực sự hoạt động hay không. Mối quan tâm này có ba tác dụng phụ sau đây.
Rất ít hoặc không tin tưởng vào việc liệu chúng tôi có thể xây dựng phần mềm hay không.
Các giai đoạn tích hợp kéo dài trước khi phân phối phần mềm trong nội bộ (ví dụ: nhóm kiểm thử) hoặc bên ngoài (ví dụ: khách hàng), trong thời gian đó không có gì khác được thực hiện.
Không có khả năng sản xuất và tái tạo các bản dựng có thể kiểm tra.
Giải pháp
Loại bỏ sự kết hợp chặt chẽ giữa IDE và các quy trình xây dựng. Chỉ sử dụng một máy riêng để tích hợp phần mềm. Đảm bảo rằng mọi thứ bạn cần để xây dựng phần mềm được chứa trong kho lưu trữ kiểm soát phiên bản. Cuối cùng, tạo một hệ thống Tích hợp liên tục.
Máy chủ Tích hợp Liên tục có thể theo dõi các thay đổi trong kho lưu trữ kiểm soát phiên bản và chạy tập lệnh xây dựng dự án khi phát hiện thay đổi đối với kho lưu trữ. Khả năng của hệ thống Tích hợp Liên tục có thể được tăng lên bao gồm việc chạy bản dựng thông qua các thử nghiệm, thực hiện kiểm tra và triển khai phần mềm trong môi trường phát triển và thử nghiệm; bằng cách này, bạn luôn có một phần mềm hoạt động.
“Inability to synchronize with the database”- Đôi khi các nhà phát triển không thể tạo lại cơ sở dữ liệu một cách nhanh chóng trong quá trình phát triển, và do đó khó thực hiện các thay đổi. Thường thì điều này là do sự tách biệt giữa nhóm cơ sở dữ liệu và nhóm phát triển. Mỗi nhóm sẽ tập trung vào trách nhiệm của riêng mình và có rất ít sự hợp tác với nhau. Mối quan tâm này có ba tác dụng phụ sau:
Sợ thực hiện thay đổi hoặc cấu trúc lại cơ sở dữ liệu hoặc mã nguồn.
Khó khăn trong việc điền vào cơ sở dữ liệu với các bộ dữ liệu thử nghiệm khác nhau.
Khó khăn trong việc duy trì môi trường phát triển và thử nghiệm (ví dụ: Phát triển, Tích hợp, QA và Thử nghiệm).
Giải pháp
Giải pháp cho vấn đề trên là đảm bảo rằng vị trí của tất cả các tạo tác cơ sở dữ liệu trong kho kiểm soát phiên bản được thực hiện. Điều này có nghĩa là mọi thứ cần thiết để tạo lại lược đồ cơ sở dữ liệu và dữ liệu: tập lệnh tạo cơ sở dữ liệu, tập lệnh thao tác dữ liệu, thủ tục được lưu trữ, trình kích hoạt và bất kỳ tài sản cơ sở dữ liệu nào khác là cần thiết.
Xây dựng lại cơ sở dữ liệu và dữ liệu từ tập lệnh xây dựng của bạn, bằng cách xóa và tạo lại cơ sở dữ liệu và bảng của bạn. Tiếp theo, áp dụng các thủ tục và trình kích hoạt đã lưu trữ, và cuối cùng, chèn dữ liệu thử nghiệm.
Kiểm tra (và kiểm tra) cơ sở dữ liệu của bạn. Thông thường, bạn sẽ sử dụng các bài kiểm tra thành phần để kiểm tra cơ sở dữ liệu và dữ liệu. Trong một số trường hợp, bạn sẽ cần viết các bài kiểm tra cơ sở dữ liệu cụ thể.
Rủi ro 2 - Phát hiện ra khiếm khuyết muộn trong vòng đời
Vì có rất nhiều thay đổi thường xuyên xảy ra bởi nhiều nhà phát triển đối với mã nguồn, nên luôn có khả năng một lỗi có thể được đưa vào mã mà chỉ có thể được phát hiện ở giai đoạn sau. Trong những trường hợp như vậy, điều này có thể gây ra tác động lớn bởi vì lỗi được phát hiện trong phần mềm càng muộn thì việc loại bỏ lỗi đó càng trở nên tốn kém.
Giải pháp
Regression Testing- Đây là khía cạnh quan trọng nhất của bất kỳ chu trình phát triển phần mềm nào, hãy kiểm tra và thử nghiệm lại. Nếu có bất kỳ thay đổi lớn nào đối với mã phần mềm, thì việc đảm bảo rằng tất cả các bài kiểm tra được chạy là điều hoàn toàn bắt buộc. Và điều này có thể được tự động hóa với sự trợ giúp của máy chủ Tích hợp Liên tục.
Test Coverage- Sẽ không có ích lợi gì khi kiểm thử nếu các trường hợp kiểm thử không bao hàm toàn bộ chức năng của mã. Điều quan trọng là đảm bảo rằng các trường hợp thử nghiệm được tạo để kiểm tra ứng dụng là hoàn chỉnh và tất cả các đường dẫn mã đều được kiểm tra.
Ví dụ: nếu bạn có màn hình đăng nhập cần được kiểm tra, bạn chỉ không thể có một trường hợp kiểm tra có kịch bản đăng nhập thành công. Bạn cần có một trường hợp kiểm tra phủ định trong đó người dùng nhập một tổ hợp tên người dùng và mật khẩu khác, sau đó bắt buộc phải xem điều gì xảy ra trong các tình huống như vậy.
Rủi ro 3 - Thiếu tầm nhìn của dự án
Các cơ chế truyền thông thủ công đòi hỏi nhiều sự phối hợp để đảm bảo việc phổ biến thông tin dự án đến đúng đối tượng một cách kịp thời. Dựa vào nhà phát triển bên cạnh bạn và cho họ biết rằng bản dựng mới nhất nằm trên bộ nhớ dùng chung khá hiệu quả, nhưng nó không mở rộng cho lắm.
Điều gì sẽ xảy ra nếu có những nhà phát triển khác cần thông tin này và họ đang nghỉ hoặc không có sẵn? Nếu máy chủ gặp sự cố, bạn sẽ được thông báo như thế nào? Một số người tin rằng họ có thể giảm thiểu rủi ro này bằng cách gửi e-mail theo cách thủ công. Tuy nhiên, điều này không thể đảm bảo thông tin được truyền đạt đến đúng người vào đúng thời điểm vì bạn có thể vô tình bỏ qua các bên quan tâm và một số có thể không có quyền truy cập vào e-mail của họ vào thời điểm đó.
Giải pháp
Giải pháp cho vấn đề này lại là máy chủ Tích hợp Liên tục. Tất cả các máy chủ CI đều có cơ sở để có các email tự động được kích hoạt bất cứ khi nào bản dựng bị lỗi. Bằng cách thông báo tự động này cho tất cả các bên liên quan chính, nó cũng đảm bảo rằng tất cả mọi người đều biết trạng thái hiện tại của phần mềm.
Rủi ro 4 - Phần mềm chất lượng thấp
Có những khuyết tật và sau đó là những khuyết tật tiềm ẩn. Bạn có thể có những khiếm khuyết tiềm ẩn khi phần mềm của bạn không được thiết kế tốt hoặc nếu nó không tuân theo các tiêu chuẩn của dự án hoặc phức tạp để bảo trì. Đôi khi mọi người gọi đây là mùi mã hoặc mùi thiết kế - "một dấu hiệu cho thấy có điều gì đó không ổn."
Một số người tin rằng phần mềm chất lượng thấp hơn chỉ là chi phí dự án hoãn lại (sau khi giao hàng). Nó có thể là chi phí dự án bị trì hoãn, nhưng nó cũng dẫn đến nhiều vấn đề khác trước khi bạn giao phần mềm cho người dùng. Mã quá phức tạp, mã không tuân theo kiến trúc và mã trùng lặp - tất cả thường dẫn đến lỗi trong phần mềm. Việc tìm ra các mã và mùi thiết kế này trước khi chúng biểu hiện thành các khiếm khuyết có thể tiết kiệm cả thời gian và tiền bạc, đồng thời có thể dẫn đến phần mềm chất lượng cao hơn.
Giải pháp
Có các thành phần phần mềm để thực hiện kiểm tra chất lượng mã có thể được tích hợp với phần mềm CI. Điều này có thể được chạy sau khi mã được xây dựng để đảm bảo rằng mã thực sự tuân thủ các nguyên tắc mã hóa thích hợp.