Tài liệu Tích hợp liên tục trong phương pháp phát triển linh hoạt (agile) pot

16/04/2013
Tích hợp liên tục trong phương pháp phát triển linh hoạt (agile) | Tạp chí Lập trình
tapchilaptrinh.wordpress.com/2013/01/28/tich-hop-lien-tuc-trong-phuong-phap-phat-trien-linh-hoat-agile/
1/10
Tạp chí Lập trình
Coding is cool ;-)
Tích hợp liên tục trong phương pháp phát triển
linh hoạt (agile)






i
2 Votes
Tìm hiểu các phương pháp agile, tích hợp liên tục và hướng kiểm thử giúp ích cho việc thiết
kế và phát triển các hệ thống phức tạp như thế nào
Martin R. Bakal, Quản lý cung ứng toàn cầu, Công nghiệp điện lực, IBM
Jennifer Althouse, Trưởng nhóm bán các sản phẩm hệ thống, IBM
Paridhi Verma, Quản lý thị trường, Công nghiệp điện lực và di động, IBM
Tóm tắt: Bài viết này tìm hiểu phương pháp phát triển linh hoạt (agile development), tích hợp liên
tục (continuous integration – CI), và phát triển theo hướng kiểm thử (test-driven development-TDD)
được sử dụng trong phát triển phần mềm nhúng. Khi áp dụng các phương pháp này vào kiến trúc dự
án thì đạt được hiệu quả chất lượng cao và tính linh hoạt.
Từ hơn một thập kỷ nay, các nhóm phần mềm đã được hưởng những lợi ích từ các phương pháp
phát triển agile. Họ đã kế tục các phương pháp phát triển tăng cường và theo vòng lặp, ở đó các giải
pháp được hình thành và phát triển thông qua những sự hợp tác. Các phương pháp tiếp cận truyền
thống không linh hoạt thường tạo ra phần mềm bằng cách phát triển tuần tự theo từng phân đoạn. Ví
dụ như quy trình thác nước (waterfall process), trong đó từng hoạt động như phân tích yêu cầu, thiết
kế, phát triển và kiểm thử được thực hiện một cách tuần tự.

16/04/2013
Tích hợp liên tục trong phương pháp phát triển linh hoạt (agile) | Tạp chí Lập trình
tapchilaptrinh.wordpress.com/2013/01/28/tich-hop-lien-tuc-trong-phuong-phap-phat-trien-linh-hoat-agile/
2/10
Mặc dù trước đây, quy trình phát triển thác nước là tiêu chuẩn để phát triển các hệ thống lớn, phức
tạp trong nhiều năm, nó cũng có những hạn chế đáng lưu ý. Đầu tiên là nó khiến lãng phí công việc
khi phải cố gắng hoàn thiện các tài liệu trước khi thiết kế và hoàn thiện các thiết kế trước khi viết mã,
mặc dù ta đã biết rõ rằng các yêu cầu sẽ thay đổi theo thời gian. Hơn nữa, khi để quá trình kiểm thử
và triển khai tích hợp đến phân khúc cuối cùng thì các vấn đề thường được phát hiện quá muộn để có
thể được giải quyết mà không làm trễ dự án. Nếu mà chúng ta đang sống trong một thế giới mà ở đó
mọi thứ đều di chuyển chậm chạp thì có thể bỏ qua 2 bước đó được. Nhưng trước áp lực phải tăng
cường tạo ra các hệ thống mang tính sáng tạo thì các tổ chức lại giảm đi nhu cầu sử dụng phương
pháp này.
Mặc dù chúng được phổ biến rộng rãi trong các nhóm phát triển hệ thống công nghệ thông tin, các
phương pháp agile cũng có thể áp dụng tốt để phát triển sản phẩm phần cứng, điện tử và phần mềm.
Phát triển phần mềm nhúng khác với việc phát triển các ứng dụng công nghệ thông tin chủ yếu ở chỗ
nó bị hạn chế khi triển khai ở các thiết bị cuối cùng, chẳng hạn như hiệu năng bộ xử lý và bộ nhớ.
Phần mềm nhúng thường thực hiện các hoạt động thời gian thực phức tạp trong những điều kiện
ràng buộc. Hãy suy nghĩ về hệ thống điều khiển bằng máy tính giống như một túi khí bảo vệ chứa
trong xe hơi. Chúng cần phải đáp ứng ngay lập tức (những khi gặp tai nạn), và cũng cần phải hoạt
động một cách đáng tin cậy. Các phương pháp agile ban đầu được thiết kế cho các đội dự án nhỏ, ở
cùng một chỗ, trong các ngành công nghiệp không chính quy. Cần phải mất nhiều năm phát triển để
phương pháp agile có thể tiếp nhận được các dự án lớn và phức tạp hơn.
Khi được dùng như một phần của phương pháp tiếp cận dựa trên kiến trúc, sự tích hợp liên tục
(Continuous Integration – CI) và phát triển theo hướng kiểm thử ( Test-Driven Development – TDD)
mở rộng phương pháp agile cơ bản đủ để cung cấp cả chất lượng cao lẫn tính linh hoạt của dự án.
Bài viết này tìm hiểu cách phương pháp agile, CI và TDD có thể được sử dụng như thế nào trong việc
phát triển phần mềm nhúng. Bài viết cũng mô tả những lợi ích của sự kết hợp này.
Bằng cách nào mà sự tích hợp liên tục và phát triển theo hướng kiểm thử phù hợp với
phương pháp agile

Giờ dây hầu hết mọi người đã nghe qua về phương pháp agile. Các khái niệm mà chúng mang đến
cho việc phát triển phần mềm đã thay đổi cách thức mà các đội nhóm tổ chức công việc của họ, cách
thích ứng với các yêu cầu luôn thay đổi và cách thức phát hành phần mềm. Tích hợp liên tục (CI)
được tạo ra cho quy trình phát triển agile, vì vậy cách tiếp cận phương pháp này là chủ đề cho bất kỳ
cuộc thảo luận nào về tích hợp liên tục. Nó tổ chức việc phát triển theo các nhóm chức năng của người
dùng. Những nhóm chức năng này được chia thành các nhóm hay các chặng công việc nhỏ.
Ý tưởng là không cố gắng giải quyết tất cả vấn đề ngay từ ban đầu, mà tập trung vào những gì bạn
đã biết. Vì vậy, nhóm nghiên cứu thiết kế, xây dựng, và kiểm thử những gì họ biết về các chức năng
mong muốn. Điều này tạo ra một sản phẩm làm việc dựa trên tập hợp con các yêu cầu của sản phẩm
hoàn chỉnh. Sau đó, cả nhóm sẽ làm việc tiếp với các yêu cầu có độ ưu tiên cao tiếp theo và cứ thế quá
trình được lặp lại. Tất nhiên, nhìn thì thấy rất đơn giản, và quy trình này cũng có nhiều biến thể khác
nhau, nhưng có một điều cốt lõi là: Từng bước xây dựng sản phẩm và dần dần cải thiện mọi thứ
trong quá trình xây dựng đó.
Theo Martin Fowler của công ty tư vấn ThoughtWorks, tích hợp liên tục (IC) là phương pháp phát
16/04/2013
Tích hợp liên tục trong phương pháp phát triển linh hoạt (agile) | Tạp chí Lập trình
tapchilaptrinh.wordpress.com/2013/01/28/tich-hop-lien-tuc-trong-phuong-phap-phat-trien-linh-hoat-agile/
3/10
Theo Martin Fowler của công ty tư vấn ThoughtWorks, tích hợp liên tục (IC) là phương pháp phát
triển phần mềm đòi hỏi các thành viên trong nhóm tích hợp công việc thường xuyên. Mỗi ngày, các
thành viên đều phải theo dõi và phát triển công việc của họ ít nhất một lần. Việc này sẽ được một
nhóm khác kiểm tra tự động, nhóm này sẽ tiến hành kiểm thử truy hồi để phát hiện lỗi nhanh nhất có
thể. Cả nhóm thấy rằng phương pháp tiếp cận này giúp giảm bớt vấn đề về tích hợp hơn và cho phép
phát triển phần mềm gắn kết nhanh hơn.
Điều này dẫn đến thành công của quá trình tích hợp liên tục. Nếu ý tưởng tích hợp liên tục là để tìm
ra các vấn đề một cách nhanh chóng thì nó mang lại cho nhà phát triển các thông tin phản hồi về công
việc của mình, sau đó sử dụng một phương pháp đánh giá công việc nhanh chóng. phát triển theo
hướng kiểm thử lấp đầy khoảng cách đó. Với phương pháp phát triển theo hướng kiểm thử, bạn xây
dựng bài kiểm thử và sau đó phát triển chức năng cho đến khi mã vượt qua được bài kiểm tra đó. Khi
có những bổ sung, bài kiểm thử cho đoạn mã đó có thể được thêm vào khi bạn cố gắng build đoạn

mã đó. Điều này đảm bảo rằng những bổ sung mới không phá vỡ công việc đã hoạt động trước đó,
và những đoạn mã nào “mang tính nguy hiểm” sẽ được cảnh báo ngay. Sự kết hợp điển hình của
tích hợp liên tục và sự phát triển theo hướng kiểm thử được minh họa trong hình 1.
Hình 1. Phương pháp agile sử dụng tích hợp liên tục và phát triển theo hướng kiểm thử
Về đầu trang
Các loại dự án được hưởng lợi từ tích hợp liên tục
Các nhóm phát triển có ít hơn 50 người làm việc trên các dự án có độ phức tạp không cao thì phù hợp
với phương pháp phát triển agile lẫn tích hợp liên tục. Tuy nhiên, vì các sản phẩm ngày càng “thông
minh hơn”, nên chúng cũng ngày càng phức tạp hơn.
Ngày càng nhiều các sản phẩm có sử dụng phần mềm nhúng. Bạn thấy những chiếc xe mới bây giờ
được tiếp thị về mã lực của nó thì ít mà về công nghệ phần mềm nhúng thì nhiều (Ví dụ: Tự vào chỗ
đỗ xe, các cảnh báo an toàn tiên tiến, hiệu quả sử dụng nhiên liệu và hệ thống thông tin giải trí). Số
lượng các dòng mã được viết để tạo ra một chiếc xe mới nhiều hơn so với số lượng các dòng mã được
viết cho một máy bay phản lực chiến đấu F16.
Với nhu cầu gia tăng độ phức tạp đồng thời các sản phẩm phải được sản xuất nhanh để đáp ứng cho
thị trường. Và việc thịnh hành của các phần mềm nhúng kết hợp với yêu cầu thời gian chặt chẽ hơn
đã mang lại sự lựa chọn cho các nhà phát triển về các phương pháp agile và tích hợp liên tục (IC).
Về đầu trang
Sử dụng các phương pháp agile để phát triển các hệ thống nhúng
Phương pháp agile cho phép các nhóm làm phần mềm và hệ thống đáp ứng sự thay đổi một cách
nhanh chóng. Cách tiếp cận linh hoạt này giúp giảm nguy cơ trễ dự án, điều mà trước đây đã gắn
liền với quy trình phát triển phần mềm truyền thống, trong đó việc tích hợp từng thành phần lại với
nhau được coi là nỗ lực ở giai đoạn cuối cùng. Giai đoạn này thường là nguyên nhân gây nhầm lẫn so
với đặc tả thiết kế ban đầu nhưng lại được phát hiện quá muộn để có thể sửa chữa cho kịp thời hạn.
16/04/2013
Tích hợp liên tục trong phương pháp phát triển linh hoạt (agile) | Tạp chí Lập trình
tapchilaptrinh.wordpress.com/2013/01/28/tich-hop-lien-tuc-trong-phuong-phap-phat-trien-linh-hoat-agile/
4/10
Tuy nhiên, đối với các nhóm phát triển hệ thống, họ là những người phải tạo ra nhiều thứ hơn là phần
mềm, thì lại hoài nghi về một số điểm ở phương pháp agile này. Họ nói rằng nếu bỏ qua quá nhiều

yếu tố khi lên kế hoạch từ ban đầu, thì cuối cùng bạn sẽ có những phần mềm kém chất lượng và
không tương thích với phần cứng. Nếu không tiến hành checkpoint (kiểm tra) sớm và thường xuyên
để xác nhận tiến độ so với kế hoạch chi tiết về kiến trúc, thì nhóm dự án có thể thất bại, không thể sản
xuất ra thành phần hoạt động được trong các hệ thống lớn. Hơn nữa, đối với các nhà phát triển hệ
thống phức tạp, những người đang tìm kiếm khả năng tái sử dụng của thiết kế hoặc khả năng mở
rộng cho các yêu cầu của dự án lớn hơn thì các phương pháp agile lại tỏ ra hạn chế.
Những lo ngại này cũng dễ hiểu, bởi vì mô hình hóa và kiến trúc không phải là điểm trọng tâm của
các kỹ thuật agile. Nhưng cách tiếp cận tích hợp liên tục đối với quá trình phát triển hệ thống cung
cấp một số cải tiến so với những phương pháp agile thuần túy. Sự tích hợp liên tục giúp các nhóm
phát triển hệ thống linh hoạt và đáp ứng với những thay đổi nghiệp vụ nhanh chóng, đồng thời cũng
đảm bảo rằng các phần cứng và phần mềm thực tế được phát triển đồng bộ liên tục. Sự tích hợp liên
tục cho phép các thành viên trong nhóm làm việc hiệu quả trong lĩnh vực của mình, tập trung vào các
nhiệm vụ mà họ đang hoàn thành một cách tốt nhất. Vào cuối mỗi ngày, họ biết rằng những đóng
góp của họ được tích hợp vào dự án và các bộ phận thành phần làm việc với nhau. Và nếu có gì đó
không được tích hợp thì nó sẽ nhanh chóng được phát hiện.
Hãy xem xét một số các thành phần thiết yếu trong phát triển và phân phối hệ thống phức tạp và
khám phá việc tích hợp liên tục (CI) giúp đáp ứng những thách thức đó như thế nào.
Kiến trúc
Khi bạn xây dựng hệ thống phức tạp, thì bạn không thể liên tục thêm các tính năng mà không cần
bản thiết kế chi tiết. Nếu không có bản thiết kế, thì có khả năng bạn sẽ phải làm lại những gì đã làm.
Cho dù bạn gọi nó là thiết kế chi tiết, mô hình hoặc kiến trúc, nó đều cung cấp một nền tảng vững
chắc mà ở đó quy trình vòng lặp được bắt đầu.
Kiến trúc có thể hữu ích trong các dự án có nhóm 50 thành viên hoặc ít hơn, nhưng khi bạn phát triển
vượt quá kích thước này, bạn chắc chắn phải có công đoạn làm sẵn trước này để hiểu cách chia thành
phần, tái sử dụng và sự biến đổi. Sự phân tích sẵn trước này cho phép bạn chia thành các nhóm
nhưng vẫn có thể kết họp lại để đưa ra sản phẩm. Điều này cũng đúng khi bạn có các nhà phát triển
phần mềm và phần cứng làm việc cùng nhau, vì bạn làm cho các hệ thống phức tạp với phần mềm
nhúng.
Mô phỏng
Bằng cách nắm bắt kiến trúc trong mô hình mô phỏng, nhóm phát triển có thể thấy cách hệ thống sẽ

đáp ứng với các đầu vào khác nhau. Hình thức kiểm thử sớm này cho phép xác nhận rằng hệ thống
thực hiện như dự định, do vậy nó đáp ứng các yêu cầu. Nó cũng cho phép nhà thiết kế hình dung bất
kỳ hậu quả không lường trước nào của thiết kế. Những hậu quả không lường trước rất khó thấy khi
xem xét mã dưới dạng văn bản. Chúng trở nên rõ ràng hơn khi xem mô hình của hệ thống và thậm
chí còn rõ ràng hơn khi hệ thống đó đang hoạt động.
Bằng cách này, việc mô hình hóa và mô phỏng cho phép bắt đầu kiểm thử và tích hợp ngay sau khi
16/04/2013
Tích hợp liên tục trong phương pháp phát triển linh hoạt (agile) | Tạp chí Lập trình
tapchilaptrinh.wordpress.com/2013/01/28/tich-hop-lien-tuc-trong-phuong-phap-phat-trien-linh-hoat-agile/
5/10
Bằng cách này, việc mô hình hóa và mô phỏng cho phép bắt đầu kiểm thử và tích hợp ngay sau khi
công việc thiết kế bắt đầu, điều này loại bỏ sự chậm trễ có thể gặp phải nếu phần cứng nhúng chưa có
sẵn. Nó có thể tiết kiệm khoản đầu tư đáng kể trong việc tạo sản phẩm mẫu sớm không cần thiết với
kiến trúc không khả thi. Ngay cả khi bạn có sẵn phần cứng, tích hợp liên tục đòi hỏi phải xây dựng
liên tục.
Nếu bạn mong muốn xem kết quả càng sớm, thì môi trường xây dựng của bạn càng trở nên đắt. Bởi
vì mục đích chính của tích hợp liên tục là cung cấp kết quả càng nhanh càng tốt, việc mô phỏng cho
phép bạn kiểm thử mà không cần chi phí phần cứng quá cao. Nó cũng cung cấp một cách dễ dàng
hơn để trao đổi thông tin về chức năng của thành phần, cách này chính là pair programming (lập
trình theo cặp đôi) và “code review (rà soát mã)”, rất phổ biến trong phát triển agile.
Tự động hóa quá trình build
Tích hợp liên tục đòi hỏi phải tự động hóa quá trình build, tức là khả năng phần mềm được tự động
biên dịch và liên kết thành tệp thực thi. Tốc độ là quan trọng bởi vì quá trình build một ứng dụng lớn
có thể mất một thời gian dài. Nếu không có công cụ build lớn, nhanh chóng, đáng tin cậy, thì bạn sẽ
thiếu những thông tin cần thiết để giải quyết các vấn đề tích hợp phát sinh. Khi build, nếu có các xung
đột hay lỗi thì trình build sẽ tự động thông báo. Vì vậy, nếu phát hiện vấn đề thì các nhà phát triển
cùng làm việc để giải quyết xung đột thông qua việc kiểm tra bản build trước đó trên một mô phỏng
phần cứng mà không làm trì hoãn các nhà phát triển khác. Nhưng để đạt được hiệu quả này, việc
xây dựng tích hợp phải diễn ra liên tục, phải tạo ra bản build mới ngay sau khi kết thúc bản build
trước đó. Điều này rất khác với cách build hàng ngày hoặc hàng tuần mà các quá trình khác sử dụng.

Tất nhiên, phương pháp này đòi hỏi tự động hóa quá trình build, bởi vì sẽ là không thực tế khi giao
cho ai đó chỉ với một nhiệm vụ là ngồi build suốt cả ngày. Hơn nữa, quá trình build cần được thực
hiện một cách nhanh chóng, điều này đòi hỏi phải chạy đa luồng (multithreaded). Quá trình
multithreaded build chính là cách build nhiều thành phần song song cùng lúc, giúp giảm bớt thời gian
build. Nó đòi hỏi nhiều phần cứng hơn và kịch bản phức tạp hơn. Kịch bản càng trở nên phức tạp, thì
công cụ quản lý việc xây dựng càng trở nên giá trị hơn.
Quản lý công việc
Khái niệm agile là việc phân chia công việc thành những phần công việc nhỏ, dễ quản lý. Đây cũng là
tiền đề cơ bản đằng sau phương pháp tích hợp liên tục: để sửa các lỗi của bạn ngay từ ban đầu. Điều
này sẽ ngăn không cho chúng kết hợp thành các vấn đề lớn hơn, khó giải quyết hơn sau này.
Một trong những điều mà kỹ thuật này mang lại là khả năng cung cấp các bản phát hành nhỏ, hoạt
động được, đã được xây dựng và kiểm thử nhiều ngày theo tiến độ của dự án. Mỗi bản phát hành
giúp giảm rủi ro của dự án bằng cách xác thực kiến trúc, các yêu cầu và ước tính lịch trình của nhóm.
Theo phương pháp agile, những công việc cần phải được hoàn thành được gọi là tồn đọng (backlog).
Khi bạn bắt đầu chia công việc thành các phần nhỏ hơn, gọi là các chặng (sprints), công việc được
phân bổ cho một sprint được gọi là sprint backlog. Phần công việc còn lại được phân bổ cho các sprint
trong tương lai được gọi là project backlog. Mục tiêu là nhóm các hạng mục công việc thành một sprint
để có thể hoàn thành được trong khoảng thời gian xác định của sprint.
Quy trình này phụ thuộc nhiều vào việc thu thập số liệu để đội có thể dự đoán chính xác lượng thời
16/04/2013
Tích hợp liên tục trong phương pháp phát triển linh hoạt (agile) | Tạp chí Lập trình
tapchilaptrinh.wordpress.com/2013/01/28/tich-hop-lien-tuc-trong-phuong-phap-phat-trien-linh-hoat-agile/
6/10
Quy trình này phụ thuộc nhiều vào việc thu thập số liệu để đội có thể dự đoán chính xác lượng thời
gian mà nhiệm vụ sẽ đòi hỏi và, do đó số lượng tác vụ có thể phù hợp với một sprint. Tuy nhiên, dù
cho những số liệu này là bao nhiêu, thì việc thu thập dữ liệu là rất mệt mỏi ngay cả đối với nhóm nhỏ.
Vì các nhóm nhỏ được gom lại với nhau để tạo ra sản phẩm phức tạp hơn, nên các tác vụ khó hoàn
thành theo cách thủ công.
Có rất nhiều sản phẩm trên thị trường giúp tổ chức công việc, theo dõi hoàn thành công việc và thống
kê các số liệu liên quan đến công việc đó như: công việc đã thực hiện được bao nhiêu, nhanh đến đâu,

tốt đến mức nào vv… Khi theo đuổi phương pháp tích hợp liên tục, thì các lỗi về tích hợp được đánh
dấu là high-priority (mức độ ưu tiên cao) và được thêm vào backlog (danh sách các công việc tồn
đọng). Về mặt này, những sản phẩm tốt nhất trên thị trường cung cấp một số mức độ tích hợp giữa
các hạng mục công việc mới và hệ thống quản lý quá trình build, do đó lỗi được xác định sau mỗi lần
build có thể được sửa một cách nhanh chóng và tích hợp với các hạng mục công việc đang có, tăng
dần theo mức ưu tiên và được chuyển đến nhóm phù hợp.
Quản lý chất lượng
Quản lý chất lượng là phương pháp phát triển vòng đời để đảm bảo rằng tất cả các yêu cầu cho sản
phẩm của bạn đã được kiểm tra. Nỗ lực này cần được tổ chức và hiểu đúng để các bài kiểm thử chính
xác có thể được cập nhật khi các yêu cầu thay đổi. Quản lý chất lượng giúp các nhà quản lý dự án trả
lời những câu hỏi sau:
Nếu sản phẩm của tôi phải được phát hành vào tuần tới, phần nào sẽ có nguy cơ cao nhất?
Chúng ta có thể phát hành mà không có yêu cầu ở mức thấp hơn?
Đây có phải là bản phát hành có chất lượng cao hay không?
Trong khi đối mặt với áp lực thị trường rằng phải đáp ứng nhanh và tăng tốc chu kỳ sản phẩm,
những câu hỏi này có thể giúp doanh nghiệp tự tin phát hành sản phẩm ra thị trường. Các nhà quản
lý hiểu rõ sẽ biết cách bổ sung các tài nguyên nào, tính năng nào nên bỏ đi và thương lượng lại ngày
giao hàng để đạt lợi thế tối đa nhất.
Với phương pháp phát triển theo hướng kiểm thử, việc kiểm thử trở thành vấn đề trung tâm hơn với
các nỗ lực phát triển. Theo phương pháp phát triển theo hướng kiểm thử, bạn viết bài kiểm thử dựa
trên yêu cầu, và sau đó bạn phát triển mã cho đến khi nó vượt qua bài kiểm thử đó. Điều này đảm
bảo rằng không có chức năng bổ sung nào được tạo ra, đó sẽ là thứ mà nhóm phát triển gọi là “mạ
vàng (gold plating)”. Thậm chí nếu bạn có một ý tưởng về một tính năng hay chức năng mới cho sản
phẩm nhưng những điều này không có trong yêu cầu thì việc thêm vào sẽ làm mất thời gian và có thể
bị trễ dự án. Đồng thời khiến cho khách hàng không hài lòng.
Tự động hóa kiểm thử
Khi bạn thực hiện quá trình build nhiều lần, thì nhóm phát triển được yêu cầu kiểm thử lại các chức
năng đã làm việc trong các phiên bản trước. Quá trình kiểm thử lại này, trước đây được biết đến là
“mã tốt (good code)”, thì nay được gọi là kiểm thử truy hồi (regression testing). Nó đảm bảo rằng
những đoạn mã trước đây sẽ không bị lỗi khi bạn thêm vào một tính năng mới nào đó. Với phương

pháp tích hợp liên tục, kiểm thử truy hồi tự động được viết thành kịch bản lệnh để chạy ở bước cuối
cùng của mỗi lần build. Điều này cho phép các nhà phát triển có được các thông tin phản hồi ngay lập
16/04/2013
Tích hợp liên tục trong phương pháp phát triển linh hoạt (agile) | Tạp chí Lập trình
tapchilaptrinh.wordpress.com/2013/01/28/tich-hop-lien-tuc-trong-phuong-phap-phat-trien-linh-hoat-agile/
7/10
tức về các lỗi được tìm thấy trong lần build mới. Đó là những cảnh báo cho nhà phát triển biết rằng
mã mới mà họ đã tạo ra có làm việc (hoặc không làm việc) như yêu cầu hay không. Nếu không có
kiểm thử truy hồi, các nhà phát triển sẽ chỉ biết rằng họ đã build thành công. Bởi vì dù sao thì cũng
phải thực hiện các bài kiểm thử, cho nên nếu ban đầu bạn sử dụng phương pháp phát triển theo
hướng kiểm thử thì sẽ không phát sinh thêm công việc này. Nó đơn giản chỉ là đảo ngược trật tự của
công việc bằng cách trước tiên tạo ra các bài kiểm thử, sau đó mới tạo mã.
Dự án phát triển theo quy trình nước truyền thống có thể sống sót mà không thực hiện bất kỳ việc
kiểm thử tự động nào. Dự án có thể được mô tả, xây dựng và sau đó được kiểm thử không ngừng
bởi rất nhiều người. Nhưng khi bạn phát hành sản phẩm một cách thường xuyên thì lúc này mới
phát sinh vấn đề. Đó là không thể kiểm thử thủ công các hệ thống đang được build nhiều lần trong
một ngày.
Sự cộng tác
Tổ chức phần mềm IBM Rational từ lâu đã là một người ủng hộ sự cộng tác như là yếu tố quan trọng
cho sự phát triển và phân phối thành công hệ thống. Nhưng trong phương pháp tích hợp liên tục, nơi
mà cả hai nhóm phần mềm và phần cứng đều tham gia, sự cộng tác không chỉ là việc kết hợp nhuần
nhuyễn sản phẩm của các đội, mà còn là sự hiểu biết đầy đủ về các yêu cầu, tính năng và thời hạn.
Đối với những kiến trúc tốt thì cho phép kiểu cộng tác này một phần vì mọi người có thể hiểu tốt hơn
các phụ thuộc giữa các thành phần khác nhau mà họ đang xây dựng. Với việc quản lý danh mục dự
án, bạn có thể hiểu các tính năng, việc tái sử dụng và phân bổ tài nguyên. Nhưng trong các dự án mà
phần cứng và phần mềm cùng phát triển, đó cũng là điều quan trọng để quản lý các yêu cầu và đưa
ra quyết định thông minh khi nào những yêu cầu có thể thay đổi và khi nào chúng không được thay
đổi.
Các dự án như vậy thường dính líu đến nhiều bên liên quan ở nhiều cấp độ của việc ra quyết định.
Cộng tác tốt sẽ giúp làm thỏa mãn các bên liên quan. Nó đảm bảo rằng sản phẩm tốt phải được tạo ra

và rằng các sai lệch so với các mục tiêu rộng lớn hơn được xác định một cách nhanh chóng. Điều này
tạo ra một sản phẩm thỏa mãn tốt hơn nhu cầu của khách hàng.
Về đầu trang
Tóm tắt
Từ góc độ kỹ thuật, tích hợp liên tục (Continuous Integration – CI) giúp các nhóm làm việc hiệu quả
hơn. Các nhóm này có thể có chức năng liên quan nhau, tạo ra phần cứng và phần mềm làm việc
cùng nhau. Họ có thể làm việc ở những nơi khác nhau, bởi vì công việc tích hợp không ngừng sẽ đảm
bảo rằng bạn không đi lệch các thiết kế. Mọi người có thể làm việc trong các nhóm lớn, bởi vì các
thành phần khác nhau của hệ thống phức tạp sẽ làm việc cùng nhau đảm bảo hơn. Nó giải quyết
nhiều vấn đề sớm mà các nhóm phát triển theo phương pháp agile có thể đã trải qua nếu không tích
hợp liên tục. Việc phối hợp phương pháp tích hợp liên tục với phương pháp phát triển theo hướng
kiểm thử đã bổ trợ cho phương pháp agile, bởi vì nó cho phép phương pháp agile làm việc hiệu quả
hơn.
Từ góc độ kinh doanh, phương pháp tích hợp liên tục cung cấp các kết quả nghiệp vụ tốt hơn bằng
16/04/2013
Tích hợp liên tục trong phương pháp phát triển linh hoạt (agile) | Tạp chí Lập trình
tapchilaptrinh.wordpress.com/2013/01/28/tich-hop-lien-tuc-trong-phuong-phap-phat-trien-linh-hoat-agile/
8/10
Từ góc độ kinh doanh, phương pháp tích hợp liên tục cung cấp các kết quả nghiệp vụ tốt hơn bằng
cách cho phép cho các nhóm đều tham gia. Nghĩa là, họ có thể đưa sản phẩm ra thị trường nhanh
hơn, bằng cách tìm ra các vấn đề khi chúng còn mới và nhỏ, không phải chờ đợi cho đến khi chúng
trở nên lớn và khó sửa chữa. Họ cũng có thể đáp ứng tốt hơn yêu cầu đưa thêm tính năng mới vào
sản phẩm trong lúc đang phát triển. Điều này tạo ra một sản phẩm tốt hơn cho khách hàng, đó là hứa
hẹn thực sự của sự linh hoạt.
Tài nguyên
Học tập
Nghe bản tin Đến thời kỳ của phương pháp Tích hợp liên tục (CI). Bạn vui lòng tìm bản tin số
#204.
Xem bản tin Áp dụng phương pháp Tích hợp liên tục trong quy trình agile để phát triển phần
mềm nhúng.

Để biết thêm thông tin về quản lý chất lượng:
Hãy xem bài viết của Moshe Cohen, Quản lý chất lượng thông minh hơn: Cách nhanh nhất để
tạo ưu thế cạnh tranh (Đây là tài liệu White Paper về những tư tưởng lãnh đạo của IBM
Software, định dạng PDF được phát hành tháng 6 năm 2011).
Hãy tìm hiểu trang web Quản lý chất lượng và kiểm thử của IBM.
Để biết thêm thông tin về phương pháp Tích hợp liên tục, hãy xem Các thực tiễn về phương pháp
Tích hợp liên tục trên trang web của Martin Fowler.
Hãy truy cập Trang phần mềm Rational trên developerWorks để có các tài nguyên kỹ thuật và
thực hành tốt nhất cho các sản phẩm Software Delivery Platform của Rational.
Đăng ký nhận bản tin developerWorks hàng tuần qua email, và chọn chủ đề để theo dõi.
Theo dõi các sự kiện kỹ thuật và các bản tin trên developerWorks về các sản phẩm của IBM và các
chủ đề ngành công nghệ thông tin.
Tham dự các lớp học miễn phí trên developerWorks để nhanh chóng tiếp cận các sản phẩm và
công cụ của IBM, cũng như xu hướng của ngành công nghệ thông tin.
Xem các bài demo theo yêu cầu trên trang developerWorks, từ việc cài đặt sản phẩm và hướng
dẫn thiết lập cho người mới bắt đầu đến các chức năng cao cấp hơn cho các nhà phát triển có kinh
nghiệm.
Lấy sản phẩm và công nghệ
Tải về phiên bản dùng thử miễn phí của phần mềm Rational.
So sánh và đánh giá các sản phẩm phần mềm của IBM theo cách riêng của bạn: Bạn có thể tải về
để dùng thử, dùng thử trực tuyến, sử dụng trong môi trường đám mây, hoặc dành một vài giờ
với SOA Sandbox để học cách triển khai một kiến trúc hướng dịch vụ hiệu quả.
Thảo luận
Tham gia diễn đàn về phần mềm Rational để đặt câu hỏi và thảo luận.
Tham gia thảo luận và nâng cao chuyên môn của bạn bằng cách vào các diễn đàn của
Rational, cafés và thư viện wikis.
Tham gia cộng đồng Rational để chia sẻ kinh nghiệm của bạn về phần mềm Rational và được kết
nối tới các đồng nghiệp.
16/04/2013
Tích hợp liên tục trong phương pháp phát triển linh hoạt (agile) | Tạp chí Lập trình

tapchilaptrinh.wordpress.com/2013/01/28/tich-hop-lien-tuc-trong-phuong-phap-phat-trien-linh-hoat-agile/
9/10
Hãy dành ít thời gian để cùng đánh giá và xem xét phần mềm Rational.
Đôi nét về các tác giả
Marty đã có hơn 10 năm kinh nghiệm làm việc với nhiều vai trò khác nhau trong các hệ thống
nhúng và ngành công nghiệp phần mềm, có mối quan hệ rộng rãi với khách hàng trên toàn thế giới
trong nhiều ngành bao gồm ngành tiêu dùng, viễn thông, ô tô và y tế. Ông hiện là quản lý cao cấp sản
phẩm toàn thế giới trong ngành công nghiệp điện tử tại trung tâm IBM Rational với vai trò dẫn dắt
các ý tưởng.
Jennifer Althouse đã có hơn 10 năm kinh nghiệm làm việc trong nhiều lĩnh vực phát triển hệ thống
phức tạp và các dự án phần mềm. Cô có mối quan hệ khách hàng rộng rãi trong nhiều ngành công
nghiệp bao gồm cả ngành hàng không vũ trụ, điện tử và thiết bị y tế. Jennifer hiện đang là Chuyên
gia công nghiệp điện tử tại IBM Rational.
Paridhi Verma là nhà quản lý thị trường ngành công nghiệp điện tử và di động tại IBM Rational, có
nhiệm vụ sáng tạo các sản phẩm thông minh hơn để phù hợp với các làn sóng mới phát triển. Cô đã
có 15 năm kinh nghiệm làm việc tại Trung tâm nghiên cứu của IBM. Mười năm cô làm việc với tư
cách là kỹ sư phần mềm bảo mật và mạng lưới. Năm năm còn lại cô phát triển các đề xuất về trao đổi
thông điệp chiến lược và giá trị khách hàng cho khu vực công nghiệp. Paridhi có bằng Thạc sĩ khoa
học về kỹ thuật điện tại đại học New York Poly. Cô cũng có bằng sáng chế cho hệ thống cảnh báo
khẩn cấp trên internet.
Nguồn:
About Phạm Anh Đới
About these ads
16/04/2013
Tích hợp liên tục trong phương pháp phát triển linh hoạt (agile) | Tạp chí Lập trình
tapchilaptrinh.wordpress.com/2013/01/28/tich-hop-lien-tuc-trong-phuong-phap-phat-trien-linh-hoat-agile/
10/10
Instructor of FPT-Aptech
View all posts by Phạm Anh Đới →
This entry was posted on Tháng Một 28, 2013 by Phạm Anh Đới in Agile, Coding Dojo, Lập Trình Căn

Bản, Lập Trình Hướng Đối Tượng and tagged continous integration, continuous testing, tdd.
/>Previous post
Next post
Blog at WordPress.com. Theme: Suburbia by WPSHOWER.