Tích hợp liên tục - Hướng dẫn nhanh

Tích hợp liên tục lần đầu tiên được giới thiệu vào năm 2000 với phần mềm được gọi là Cruise Control. Trong những năm qua, Tích hợp liên tục đã trở thành một thông lệ quan trọng trong bất kỳ tổ chức phần mềm nào. Đây là một thực tiễn phát triển kêu gọi các nhóm phát triển đảm bảo rằng việc xây dựng và thử nghiệm tiếp theo được tiến hành cho mọi thay đổi mã được thực hiện đối với một chương trình phần mềm. Khái niệm này nhằm loại bỏ vấn đề tìm kiếm các sự cố xuất hiện muộn trong vòng đời xây dựng. Thay vì các nhà phát triển làm việc riêng lẻ và không tích hợp đủ, Tích hợp liên tục được giới thiệu để đảm bảo rằng các thay đổi và xây dựng mã không bao giờ được thực hiện một cách cô lập.

Tại sao phải tích hợp liên tục?

Tích hợp liên tục đã trở thành một phần rất không thể thiếu trong bất kỳ quá trình phát triển phần mềm nào. Quá trình Tích hợp liên tục giúp trả lời các câu hỏi sau cho nhóm phát triển phần mềm.

  • Tất cả các thành phần phần mềm có hoạt động cùng nhau như bình thường không? - Đôi khi các hệ thống có thể trở nên phức tạp đến mức có nhiều giao diện cho mỗi thành phần. Trong những trường hợp như vậy, điều quan trọng là phải đảm bảo rằng tất cả các thành phần phần mềm hoạt động trơn tru với nhau.

  • Mã có quá phức tạp cho mục đích tích hợp không? - Nếu quá trình tích hợp liên tục liên tục không thành công, có thể có khả năng mã quá phức tạp. Và đây có thể là một tín hiệu để áp dụng các mẫu thiết kế phù hợp để làm cho mã ít phức tạp hơn và dễ bảo trì hơn.

  • Mã có tuân thủ các tiêu chuẩn mã hóa đã thiết lập không? - Hầu hết các trường hợp thử nghiệm sẽ luôn kiểm tra xem mã có tuân thủ các tiêu chuẩn mã hóa thích hợp hay không. Bằng cách thực hiện kiểm tra tự động sau khi xây dựng tự động, đây là một điểm tốt để kiểm tra xem mã có đáp ứng tất cả các tiêu chuẩn mã hóa mong muốn hay không.

  • Bao nhiêu mã được bao phủ bởi các bài kiểm tra tự động? - Sẽ không có ích lợi gì trong việc kiểm tra mã nếu các trường hợp kiểm thử không bao hàm các chức năng cần thiết của mã. Vì vậy, luôn luôn là một thực tiễn tốt để đảm bảo rằng các trường hợp thử nghiệm được viết phải bao gồm tất cả các tình huống chính của ứng dụng.

  • Tất cả các thử nghiệm có thành công sau thay đổi mới nhất không? - Nếu một thử nghiệm không thành công, thì không có điểm nào trong việc tiếp tục triển khai mã, vì vậy đây là một điểm tốt để kiểm tra xem mã đã sẵn sàng để chuyển sang giai đoạn triển khai hay chưa.

Quy trình làm việc

Hình ảnh sau đây cho thấy quy trình làm việc nhanh chóng về cách toàn bộ quy trình tích hợp liên tục hoạt động trong bất kỳ dự án phát triển phần mềm nào. Chúng ta sẽ xem xét chi tiết điều này trong các chương tiếp theo.

Vì vậy, dựa trên quy trình làm việc ở trên, đây thường là cách hoạt động của quá trình tích hợp liên tục.

  • Đầu tiên, nhà phát triển cam kết mã với kho lưu trữ kiểm soát phiên bản. Trong khi đó, máy chủ Tích hợp liên tục trên máy xây dựng tích hợp sẽ thăm dò kho lưu trữ mã nguồn để tìm các thay đổi (ví dụ: vài phút một lần).

  • Ngay sau khi một cam kết xảy ra, máy chủ Tích hợp Liên tục phát hiện những thay đổi đã xảy ra trong kho lưu trữ kiểm soát phiên bản, do đó, máy chủ Tích hợp Liên tục lấy bản sao mới nhất của mã từ kho lưu trữ và sau đó thực thi một tập lệnh xây dựng, tích hợp phần mềm

  • Máy chủ Tích hợp Liên tục tạo phản hồi bằng cách gửi thư điện tử kết quả xây dựng cho các thành viên dự án được chỉ định.

  • Các bài kiểm tra đơn vị sau đó được thực hiện nếu quá trình xây dựng của dự án đó vượt qua. Nếu các thử nghiệm thành công, mã đã sẵn sàng để được triển khai tới máy chủ dàn hoặc máy chủ sản xuất.

  • Máy chủ Tích hợp Liên tục tiếp tục thăm dò các thay đổi trong kho kiểm soát phiên bản và toàn bộ quá trình lặp lại.

Phần phần mềm là khía cạnh quan trọng nhất của bất kỳ quy trình Tích hợp Liên tục nào. Chương này tập trung vào phần mềm sẽ cần thiết cho toàn bộ quá trình Tích hợp liên tục.

Kho lưu trữ mã nguồn

Kho lưu trữ mã nguồn được sử dụng để duy trì tất cả mã nguồn và tất cả các thay đổi được thực hiện đối với nó. Hai cái phổ biến nhất để quản lý kho mã nguồn là subversion và Git với Git là hệ thống phổ biến gần đây nhất. Bây giờ chúng ta sẽ xem xét cách cài đặt Git trên hệ thống.

yêu cầu hệ thống

Ký ức RAM 2 GB (khuyến nghị)
Dung lượng đĩa Ổ cứng 200 MB để cài đặt. Cần có thêm bộ nhớ để lưu trữ mã nguồn dự án và điều này phụ thuộc vào mã nguồn được thêm vào.
Phiên bản hệ điều hành Có thể cài đặt trên Windows, Ubuntu / Debian, Red Hat / Fedora / CentOS, Mac OS X.

Cài đặt Git

Step 1 - Trang web chính thức của Git là https://git-scm.com/. Nếu bạn nhấp vào liên kết, bạn sẽ đến trang chủ của trang web chính thức của Git như được hiển thị trong ảnh chụp màn hình sau.

Step 2 - Để tải Git, bạn chỉ cần kéo màn hình xuống và vào phần Tải xuống và nhấp vào Tải xuống.

Step 3 - Nhấp vào liên kết Windows và quá trình tải xuống Git sẽ tự động bắt đầu.

Step 4- Nhấp vào tệp .exe đã tải xuống cho Git. Trong trường hợp của chúng tôi, chúng tôi đang sử dụng tệp Git-2.6.1-64-bit.exe. Nhấp vào Chạy xuất hiện trên màn hình tiếp theo.

Step 5 - Nhấp vào nút Tiếp theo xuất hiện trên màn hình sau.

Step 6 - Nhấp vào Tiếp theo trong màn hình sau để chấp nhận thỏa thuận Cấp phép Chung.

Step 7 - Chọn vị trí để cài đặt Git của bạn.

Step 8 - Nhấn Next để chấp nhận các thành phần mặc định cần được cài đặt.

Step 9 - Chọn tùy chọn 'Sử dụng Git từ dấu nhắc lệnh Windows' vì chúng ta sẽ sử dụng Git từ Windows.

Step 10 - Trong màn hình sau, chấp nhận cài đặt mặc định 'Checkout kiểu Windows, cam kết kết thúc dòng kiểu Unix' và nhấp vào Tiếp theo.

Step 11 - Trong màn hình sau, chọn tùy chọn 'Sử dụng cửa sổ bảng điều khiển mặc định của Windows', vì chúng tôi đang sử dụng Windows làm hệ thống cài đặt Git.

Cài đặt bây giờ sẽ bắt đầu và các bước tiếp theo có thể được thực hiện để cấu hình Git, sau khi quá trình cài đặt hoàn tất.

Định cấu hình Git

Khi Git đã được cài đặt, các bước cấu hình cần được thực hiện cho cấu hình ban đầu của Git.

Điều đầu tiên cần làm là cấu hình danh tính trong Git, sau đó cấu hình tên người dùng và email. Điều này rất quan trọng vì mọiGit commitsử dụng thông tin này và nó luôn được đưa vào các cam kết mà bạn bắt đầu tạo. Người ta có thể làm điều này bằng cách mở dấu nhắc lệnh và sau đó nhập các lệnh sau:

git config –global user.name “Username”
git config –global user.email “emailid”

Ảnh chụp màn hình sau đây là một ví dụ để hiểu rõ hơn.

Các lệnh này sẽ thực sự thay đổi tệp cấu hình của Git cho phù hợp. Để đảm bảo cài đặt của bạn đã có hiệu lực, bạn có thể liệt kê các cài đặt của tệp cấu hình Git bằng cách sử dụng lệnh sau.

git config --list

Ví dụ về đầu ra được hiển thị trong ảnh chụp màn hình sau.

Máy chủ tích hợp liên tục

Phần mềm quan trọng tiếp theo được yêu cầu cho toàn bộ quy trình tích hợp liên tục là bản thân phần mềm Tích hợp liên tục. Sau đây là các phần mềm Tích hợp liên tục được sử dụng phổ biến nhất được sử dụng trong ngành:

  • Jenkins- Đây là phần mềm tích hợp liên tục mã nguồn mở được rất nhiều cộng đồng phát triển sử dụng.

  • Jet Brains TeamCity - Đây là một trong những phần mềm Tích hợp Liên tục thương mại phổ biến nhất hiện có và hầu hết các công ty sử dụng phần mềm này cho nhu cầu Tích hợp Liên tục của họ.

  • Atlassian Bamboo- Đây là một phần mềm Tích hợp Liên tục phổ biến khác được cung cấp bởi một công ty có tên Atlassian Pvt. Ltd.

Tất cả các phần mềm được đề cập ở trên, hoạt động trên cùng một mô hình để Tích hợp liên tục. Với mục đích của hướng dẫn này, chúng ta sẽ xem xétJetbrains TeamCity cho máy chủ Tích hợp liên tục.

Cài đặt TeamCity

Sau đây là các bước và yêu cầu hệ thống để cài đặt Jet Brains TeamCity trong máy tính của bạn.

yêu cầu hệ thống

Ký ức RAM 4 GB (khuyến nghị)
Dung lượng đĩa Ổ cứng 1 GB để cài đặt. Cần có thêm bộ nhớ để lưu trữ không gian làm việc xây dựng cho mỗi dự án.
Phiên bản hệ điều hành Có thể cài đặt trên Windows, Linux, Mac OS X.

Cài đặt

Step 1 - Trang web chính thức của TeamCity làhttps://www.jetbrains.com/teamcity/. Nếu bạn nhấp vào liên kết nhất định, bạn sẽ đến trang chủ của trang web chính thức của TeamCity như được hiển thị trong ảnh chụp màn hình sau. Bạn có thể duyệt trang để tải xuống phần mềm cần thiết cho TeamCity.

Step 2 - Tệp .exe đã tải xuống đang được sử dụng cho mục đích thực thi TeamCity-9.1.6.exe. Bấm đúp vào tệp thực thi và sau đó bấm Chạy trong màn hình tiếp theo bật lên.

Step 3 - Nhấn Next để bắt đầu thiết lập.

Step 4 - Nhấp vào nút 'I Agree' để chấp nhận thỏa thuận cấp phép và tiến hành cài đặt.

Step 5 - Chọn vị trí cài đặt và nhấn Next.

Step 6 - Chọn các thành phần mặc định để cài đặt và nhấp vào Tiếp theo

Điều này sẽ bắt đầu quá trình cài đặt. Sau khi hoàn thành quá trình cấu hình sẽ theo sau.

Step 7- Chọn số cổng để máy chủ chạy. Tốt nhất là sử dụng một cổng khác chẳng hạn như8080.

Step 8- Tiếp theo nó sẽ hỏi TeamCity cần chạy tài khoản nào. Chọn tài khoản HỆ THỐNG và nhấp vào Tiếp theo.

Step 9- Tiếp theo, nó sẽ yêu cầu các dịch vụ cần được bắt đầu. Chấp nhận những cái mặc định và sau đó nhấp vào Tiếp theo.

Cấu hình TeamCity

Sau khi cài đặt xong, bước tiếp theo là cấu hình TeamCity. Phần mềm này có thể được mở bằng cách duyệt trên URL sau trong trình duyệt -

http://locahost:8080

Step 1- Bước đầu tiên là cung cấp vị trí của các công trình sẽ do TeamCity thực hiện. Chọn vị trí mong muốn và nhấp vào nút Tiếp tục.

Step 2- Bước tiếp theo là chỉ định cơ sở dữ liệu để lưu trữ tất cả các đồ tạo tác TeamCity. Đối với mục đích của hướng dẫn, người ta có thể chọnInternal (HSQLDB), là cơ sở dữ liệu nội bộ phù hợp nhất khi sử dụng sản phẩm cho mục đích thử nghiệm.

TeamCity sau đó sẽ xử lý tất cả các bước cần thiết để thiết lập và chạy nó.

Step 3- Tiếp theo, bạn sẽ được yêu cầu Chấp nhận thỏa thuận cấp phép. Chấp nhận tương tự và nhấp vào Tiếp tục.

Step 4- Bạn cần tạo một tài khoản quản trị để đăng nhập vào phần mềm TeamCity. Nhập các chi tiết cần thiết và nhấp vào nút 'Tạo Tài khoản'.

Bây giờ bạn sẽ được đăng nhập vào TeamCity.

Công cụ xây dựng

Công cụ Build là một công cụ đảm bảo rằng chương trình được xây dựng theo một cách cụ thể. Công cụ này thông thường sẽ thực hiện một danh sách các nhiệm vụ, các nhiệm vụ này được yêu cầu để chương trình được xây dựng một cách phù hợp. Vì trong ví dụ của chúng tôi, chúng tôi sẽ xem xét một.Net program , chúng tôi sẽ xem xét MSBuildlàm công cụ xây dựng. Công cụ MSBuild xem xét một tệp xây dựng chứa danh sách các tác vụ được sử dụng để xây dựng dự án. Hãy xem xét một tệp Xây dựng điển hình cho một dự án cấu hình web.

Sau đây là các phần chính của tệp Xây dựng, cần được xem xét.

Cài đặt IIS

Các cài đặt sau được sử dụng để xác định đâu là số cổng, đâu là đường dẫn trên máy chủ web và loại xác thực nào được yêu cầu khi ứng dụng được chạy. Đây là những cài đặt quan trọng, sẽ được thay đổi thông qua lệnh MSBuild khi chúng ta tìm hiểu cách triển khai sẽ được thực hiện ở phần sau trong hướng dẫn.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPor>
<DevelopmentServerPort>61581</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>http://localhost:61581/</IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>

Nhóm mục

Điều này được sử dụng để cho máy chủ Xây dựng biết tất cả các tệp nhị phân phụ thuộc được yêu cầu để chạy dự án này.

<ItemGroup>
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />

<ItemGroup>
   <Compile Include = "App_Start\BundleConfig.cs" />
   <Compile Include = "App_Start\FilterConfig.cs" />

Phiên bản .Net Framework

Các TargetFrameworkVersioncho biết đâu là phiên bản .Net cần có mặt để dự án hoạt động. Điều này là hoàn toàn cần thiết vì nếu máy chủ xây dựng không có sẵn điều này, quá trình xây dựng sẽ không thành công.

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

Môi trường triển khai - Amazon

Với mục đích của hướng dẫn này, chúng tôi sẽ đảm bảo máy chủ Tích hợp liên tục của chúng tôi có khả năng triển khai ứng dụng của chúng tôi lên Amazon. Đối với điều này, chúng tôi cần đảm bảo các đồ tạo tác sau đây được đặt đúng chỗ.

Máy chủ cơ sở dữ liệu

Thực hiện các bước sau để đảm bảo rằng máy chủ cơ sở dữ liệu được đặt sẵn trong Amazon để triển khai.

Step 1 - Truy cập Bảng điều khiển Amazon - https://aws.amazon.com/console/.

Đăng nhập bằng thông tin đăng nhập của bạn. Lưu ý rằng bạn có thể đăng ký id miễn phí trên trang amazon, điều này sẽ cho phép bạn có một cấp miễn phí cho phép bạn sử dụng miễn phí một số tài nguyên trên Amazon.

Step 2 - Chuyển đến Phần RDS để tạo cơ sở dữ liệu của bạn.

Step 3 - Nhấp vào Phiên bản trong màn hình tiếp theo bật lên.

Step 4 - Nhấp vào Launch DB trong màn hình tiếp theo xuất hiện.

Step 5 - Chọn tab SQL Server và sau đó chọn tùy chọn Chọn cho SQL Server Express.

Step 6 - Đảm bảo rằng các chi tiết sau đây được nhập để xác nhận rằng bạn đang sử dụng cấp cơ sở dữ liệu miễn phí có sẵn từ Amazon.

Step 7 - Nhấp vào nút Bước Tiếp theo khi tất cả các trường đã được điền.

Step 8 - Trong màn hình tiếp theo xuất hiện, chấp nhận tất cả các cài đặt mặc định và nhấp vào Launch DB Instance.

Step 9- Sau đó, bạn sẽ thấy một màn hình cho biết rằng DB đang được khởi chạy thành công. Trên cùng một trang, sẽ có một nút để xem Phiên bản DB. Nhấp vào liên kết để xemDB Instance Đang được thiết lập.

Sau một thời gian, trạng thái của màn hình trên sẽ thay đổi để thông báo rằng Phiên bản DB đã được tạo thành công.

Máy chủ web

Bước tiếp theo là tạo máy chủ web của bạn trên Amazon, máy chủ này sẽ lưu trữ ứng dụng web. Điều này có thể được thực hiện bằng cách làm theo các bước tiếp theo để thực hiện điều này.

Step 1 - Truy cập Amazon Console - https://aws.amazon.com/console/.

Đăng nhập bằng thông tin đăng nhập của bạn. Lưu ý rằng bạn có thể đăng kýfree id on the Amazon site, điều này sẽ cho phép bạn có một cấp miễn phí cho phép bạn sử dụng miễn phí một số tài nguyên trên Amazon.

Step 2 - Đi đến EC2 section để tạo máy chủ web của bạn.

Step 3 - Trong màn hình tiếp theo, nhấp vào Launch Instance.

Step 4 - Nhấp vào Windows - Microsoft Windows Server 2010 R2 Base.

Step 5 - Chọn t2.microtùy chọn, là một phần của cấp miễn phí. Nhấp chuộtNext: Configure Instance Details.

Step 6 - Chấp nhận cài đặt mặc định trên màn hình tiếp theo xuất hiện và sau đó chọn tùy chọn Next: Add Storage.

Step 7 - Chấp nhận cài đặt mặc định trên màn hình tiếp theo và chọn tùy chọn Next: Tag Instance.

Step 8 - Chấp nhận cài đặt mặc định trên màn hình tiếp theo và chọn tùy chọn Next: Configure Security Group.

Step 9 - Chấp nhận cài đặt mặc định trên màn hình tiếp theo và chọn tùy chọn Review and Launch.

Step 10 - Nhấp vào Khởi chạy trong màn hình tiếp theo xuất hiện.

Step 11- Trong màn hình tiếp theo xuất hiện, bạn sẽ được nhắc tạo một cặp khóa. Điều này sẽ được sử dụng để đăng nhập vào máy chủ sau này. Chỉ cần tạo cặp khóa và nhấp vàoLaunch Instance.

Phiên bản bây giờ sẽ được thiết lập trong Amazon.

Có khả năng mọi thứ sẽ diễn ra sai 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 đề hơ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ự tự tin về việc 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 tra) 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 đội 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 các 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, điều bắt buộc là hoàn toàn phải đảm bảo rằng tất cả các thử nghiệm đều được chạy. 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 phải 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ó mặt? 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 lỗi 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.

Hệ thống kiểm soát phiên bản, còn được gọi là kiểm soát nguồn, hệ thống quản lý mã nguồn hoặc hệ thống kiểm soát sửa đổi, là một cơ chế để giữ nhiều phiên bản tệp của bạn, để khi bạn sửa đổi tệp, bạn vẫn có thể truy cập vào các bản sửa đổi trước đó.

Hệ thống kiểm soát phiên bản phổ biến đầu tiên là một công cụ UNIX độc quyền được gọi là SCCS(Hệ thống kiểm soát mã nguồn) có từ những năm 1970. Điều này đã được thay thế bởiRCS, Hệ thống kiểm soát sửa đổi và sau này CVS, Hệ thống Phiên bản Đồng thời.

Giờ đây, hệ thống kiểm soát phiên bản phổ biến nhất được sử dụng là Subversion và Git. Trước tiên, hãy xem lý do tại sao chúng ta cần sử dụng hệ thống kiểm soát lập phiên bản và tiếp theo hãy xem xét việc đưa mã nguồn của chúng ta vàoGit source code repository system.

Mục đích của Hệ thống Kiểm soát Phiên bản

Một lý do mà chúng tôi sử dụng thuật ngữ kiểm soát phiên bản thay vì kiểm soát nguồn là kiểm soát phiên bản không chỉ dành cho mã nguồn. Mọi tạo tác liên quan đến việc tạo ra phần mềm của bạn phải được kiểm soát phiên bản.

    Developers should use it for source code - Theo mặc định, tất cả mã nguồn cần được lưu trữ trong hệ thống kiểm soát phiên bản

    Related artefacts- Mọi hệ thống sẽ có các thành phần liên quan đến mã nguồn như tập lệnh cơ sở dữ liệu, tập lệnh xây dựng và triển khai, tài liệu, thư viện và tệp cấu hình cho ứng dụng của bạn, trình biên dịch và bộ sưu tập công cụ của bạn, v.v. Tất cả những điều này khen ngợi toàn bộ quá trình phát triển và triển khai và cũng cần được lưu trữ trong hệ thống kiểm soát lập phiên bản.

Bằng cách lưu trữ tất cả thông tin cho ứng dụng trong kiểm soát nguồn, việc tạo lại môi trường thử nghiệm và sản xuất mà ứng dụng của bạn chạy trên đó trở nên dễ dàng hơn. Điều này phải bao gồm thông tin cấu hình cho ngăn xếp phần mềm của ứng dụng của bạn và hệ điều hành bao gồm môi trường, Tệp vùng DNS, Cấu hình tường lửa, v.v.

Ở mức tối thiểu, bạn cần mọi thứ cần thiết để tạo lại các tệp nhị phân của ứng dụng và môi trường mà chúng chạy. Mục tiêu là để mọi thứ có thể thay đổi ở bất kỳ thời điểm nào trong vòng đời của dự án được lưu trữ một cách có kiểm soát. Điều này cho phép bạn khôi phục ảnh chụp nhanh chính xác về trạng thái của toàn bộ hệ thống, từ môi trường phát triển đến môi trường sản xuất, tại bất kỳ thời điểm nào trong lịch sử của dự án.

Việc giữ các tệp cấu hình cho môi trường phát triển của nhóm phát triển trong quyền kiểm soát phiên bản thậm chí còn hữu ích vì nó giúp mọi người trong nhóm dễ dàng sử dụng các cài đặt giống nhau. Các nhà phân tích nên lưu trữ các tài liệu yêu cầu. Người kiểm tra nên giữ các tập lệnh và quy trình kiểm tra của họ trong kiểm soát phiên bản. Người quản lý dự án nên lưu kế hoạch phát hành, biểu đồ tiến độ và nhật ký rủi ro của họ tại đây.

Tóm lại, mọi thành viên của nhóm nên lưu trữ bất kỳ tài liệu hoặc tệp nào liên quan đến dự án trong kiểm soát phiên bản.

Làm việc với Git cho Hệ thống kiểm soát phiên bản mã nguồn

Phần này bây giờ sẽ tập trung vào cách Git có thể được sử dụng như một hệ thống điều khiển lập phiên bản. Nó sẽ tập trung vào cách bạn có thể tải mã của mình lên hệ thống kiểm soát lập phiên bản và quản lý các thay đổi trong đó.

Ứng dụng Demo của chúng tôi

Đối với mục đích của toàn bộ hướng dẫn này, chúng ta sẽ xem xét một Web ASP.Netứng dụng sẽ được sử dụng cho toàn bộ Quy trình Tích hợp Liên tục. Chúng ta không cần tập trung vào toàn bộ chi tiết mã cho bài tập này, chỉ cần có một cái nhìn tổng quan về những gì dự án làm là đủ để hiểu toàn bộ quá trình tích hợp liên tục. Ứng dụng .Net này được tạo bằng cách sử dụngVisual Studio Integrated Development Environment.

Ảnh chụp màn hình sau đây là cấu trúc của giải pháp trong môi trường Visual Studio. Nó là một ứng dụng Web rất đơn giản có mã chính trongDemo.aspx tập tin.

Mã trong tệp Demo.aspx được hiển thị trong chương trình sau:

<html xmlns = "http://www.w3.org/1999/xhtml">
   <head runat = "server">
      <title>TutorialsPoint</title>
   </head>
   
   <body>
      <form id = "form1" runat="server">
         <div><%Response.Write("Continuous Integration"); %></div>
      </form>
   </body>
   
</html>

Mã rất đơn giản và chỉ xuất chuỗi “Tích hợp liên tục” cho trình duyệt.

Khi bạn chạy dự án trong Google Chrome, đầu ra sẽ như trong ảnh chụp màn hình sau.

Chuyển mã nguồn sang Git

Chúng tôi sẽ trình bày cách chuyển mã nguồn sang Git từ giao diện dòng lệnh, để người dùng cuối hiểu rõ hơn về cách sử dụng Git.

Step 1 - Khởi tạo Git Repository. Đi tới dấu nhắc lệnh, đi tới thư mục dự án của bạn và đưa ra lệnhgit init. Lệnh này sẽ thêm các tệp Git cần thiết vào thư mục dự án, để Git có thể nhận ra nó khi cần tải lên kho lưu trữ.

Step 2- Thêm các tệp của bạn cần được thêm vào kho lưu trữ Git. Điều này có thể được thực hiện bằng cách phát hànhgit add command. Tùy chọn dấu chấm cho Git biết rằng tất cả các tệp trong thư mục dự án cần được thêm vào kho lưu trữ Git.

Step 3- Bước cuối cùng là cam kết các tệp dự án vào kho lưu trữ Git. Bước này là bắt buộc để đảm bảo tất cả các tệp hiện là một phần của Git. Lệnh sẽ được đưa ra trong ảnh chụp màn hình sau. Các–m option là cung cấp một nhận xét cho việc tải lên các tệp.

Giải pháp của bạn hiện đã có trong Git.

Sau đây là một số tính năng hoặc thực tiễn chính để Tích hợp liên tục.

  • Maintain a single source repository- Tất cả mã nguồn được duy trì trong một kho lưu trữ duy nhất. Điều này tránh để mã nguồn bị phân tán trên nhiều vị trí. Các công cụ nhưSubversion and Git là những công cụ phổ biến nhất để duy trì mã nguồn.

  • Automate the build- Việc xây dựng phần mềm nên được thực hiện theo cách mà nó có thể được tự động hóa. Nếu có nhiều bước cần được thực hiện, thì công cụ xây dựng cần có khả năng thực hiện việc này. Đối với .Net, MSBuild là công cụ xây dựng mặc định và đối với các ứng dụng dựa trên Java, bạn có các công cụ nhưMaven and Grunt.

  • Make your build self-testing- Bản dựng phải có thể kiểm tra được. Ngay sau khi quá trình xây dựng xảy ra, các trường hợp kiểm thử phải được chạy để đảm bảo rằng việc kiểm thử có thể được thực hiện cho các chức năng khác nhau của phần mềm.

  • Every commit should build on an integration machine- Máy tích hợp là máy chủ bản dựng và cần đảm bảo rằng bản dựng chạy trên máy này. Điều này có nghĩa là tất cả các thành phần phụ thuộc phải tồn tại trên máy chủ Tích hợp Liên tục.

  • Keep the build fast- Việc xây dựng sẽ diễn ra trong vài phút. Quá trình xây dựng sẽ không mất nhiều giờ để diễn ra, vì điều này có nghĩa là các bước xây dựng không được định cấu hình đúng.

  • Test in a clone of the production environment- Môi trường xây dựng cần gần gũi thiên nhiên với môi trường sản xuất. Nếu có sự khác biệt lớn giữa các môi trường này, thì có thể có trường hợp bản dựng có thể bị lỗi trong quá trình sản xuất mặc dù nó được chuyển trên máy chủ bản dựng.

  • Everyone can see what is happening - Toàn bộ quá trình xây dựng và thử nghiệm và triển khai phải được hiển thị cho tất cả mọi người.

  • Automate deployment- Tích hợp liên tục dẫn đến triển khai liên tục. Hoàn toàn cần thiết để đảm bảo rằng bản dựng phải dễ dàng triển khai trên môi trường dàn dựng hoặc sản xuất.

Sau đây là danh sách các yêu cầu quan trọng nhất đối với Tích hợp liên tục.

  • Check-In Regularly- Thực hành quan trọng nhất để tích hợp liên tục hoạt động bình thường là thường xuyên đăng ký vào đường trục hoặc đường chính của kho mã nguồn. Việc đăng ký mã nên diễn ra ít nhất một vài lần một ngày. Đăng ký thường xuyên mang lại rất nhiều lợi ích khác. Nó làm cho các thay đổi nhỏ hơn và do đó ít có khả năng phá vỡ cấu trúc hơn. Nó có nghĩa là phiên bản mới nhất của phần mềm cần hoàn nguyên sẽ được biết khi có lỗi xảy ra trong bất kỳ bản dựng tiếp theo nào.

    Nó cũng giúp bạn có kỷ luật hơn trong việc cấu trúc lại mã và tuân theo những thay đổi nhỏ để duy trì hành vi. Nó giúp đảm bảo rằng các thay đổi làm thay đổi nhiều tệp ít có khả năng xung đột với công việc của người khác. Nó cho phép các nhà phát triển khám phá nhiều hơn, thử các ý tưởng và loại bỏ chúng bằng cách hoàn nguyên về phiên bản cam kết cuối cùng.

  • Create a Comprehensive Automated Test Suite- Nếu bạn không có bộ kiểm tra tự động toàn diện, bản dựng vượt qua chỉ có nghĩa là ứng dụng có thể được biên dịch và lắp ráp. Mặc dù đối với một số nhóm, đây là một bước tiến lớn, nhưng điều cần thiết là phải có một số cấp độ kiểm tra tự động để cung cấp niềm tin rằng ứng dụng của bạn đang thực sự hoạt động.

    Thông thường, có 3 loại kiểm tra được thực hiện trong Tích hợp liên tục là unit tests, component testsvà acceptance tests.

    Bài kiểm tra đơn vị được viết để kiểm tra hành vi của các phần nhỏ ứng dụng của bạn một cách riêng biệt. Chúng thường có thể được chạy mà không cần khởi động toàn bộ ứng dụng. Chúng không đánh vào cơ sở dữ liệu (nếu ứng dụng của bạn có), hệ thống tệp hoặc mạng. Họ không yêu cầu ứng dụng của bạn phải chạy trong một môi trường giống như sản xuất. Các bài kiểm tra đơn vị sẽ chạy rất nhanh - toàn bộ bộ ứng dụng của bạn, ngay cả đối với một ứng dụng lớn, sẽ có thể chạy trong vòng chưa đầy mười phút.

    Kiểm tra thành phần kiểm tra hành vi của một số thành phần trong ứng dụng của bạn. Giống như các bài kiểm tra đơn vị, chúng không phải lúc nào cũng yêu cầu khởi động toàn bộ ứng dụng. Tuy nhiên, chúng có thể tấn công cơ sở dữ liệu, hệ thống tệp hoặc các hệ thống khác (có thể bị lỗi). Kiểm tra thành phần thường mất nhiều thời gian hơn để chạy.

  • Keep the Build and Test Process Short - Nếu mất quá nhiều thời gian để xây dựng mã và chạy các bài kiểm tra đơn vị, bạn sẽ gặp phải các vấn đề sau.

    • Mọi người sẽ ngừng xây dựng đầy đủ và sẽ chạy các bài kiểm tra trước khi họ đăng ký. Bạn sẽ bắt đầu nhận được nhiều bản dựng thất bại hơn.

    • Quá trình Tích hợp liên tục sẽ mất nhiều thời gian đến nỗi có nhiều cam kết sẽ diễn ra vào thời điểm bạn có thể chạy lại bản dựng, vì vậy bạn sẽ không biết đăng ký nào đã phá vỡ bản dựng.

    • Mọi người sẽ ít đăng ký hơn vì họ phải ngồi đợi nhiều tuổi để chờ phần mềm xây dựng và chạy thử nghiệm.

  • Don’t Check-In on a Broken Build- Sai lầm lớn nhất của việc tích hợp liên tục là đăng ký một bản dựng bị hỏng. Nếu bản dựng bị hỏng, các nhà phát triển chịu trách nhiệm đang đợi để sửa nó. Họ xác định nguyên nhân gây ra vỡ càng sớm càng tốt và sửa chữa nó. Nếu chúng tôi áp dụng chiến lược này, chúng tôi sẽ luôn ở vị trí tốt nhất để tìm ra nguyên nhân gây ra sự cố và khắc phục nó ngay lập tức.

    Nếu một trong những đồng nghiệp của chúng tôi đã thực hiện đăng ký và kết quả là làm hỏng bản dựng, thì để có cơ hội tốt nhất để sửa chữa nó, họ sẽ cần phải giải quyết rõ ràng vấn đề. Khi quy tắc này bị phá vỡ, chắc chắn sẽ mất nhiều thời gian hơn để bản dựng được sửa. Mọi người quen với việc nhìn thấy công trình xây dựng bị hỏng, và rất nhanh chóng bạn sẽ rơi vào tình trạng công trình xây dựng luôn bị hỏng.

  • Always Run All Commit Tests Locally Before Committing- Luôn đảm bảo rằng các bài kiểm tra được thiết kế cho ứng dụng được chạy trước trên một máy cục bộ trước khi chạy chúng trên máy chủ CI. Điều này là để đảm bảo các trường hợp kiểm thử phù hợp được viết và nếu có bất kỳ lỗi nào trong quá trình CI thì đó là do kết quả kiểm tra không thành công.

  • Take Responsibility for All Breakages that Result from Your Changes- Nếu bạn thực hiện một thay đổi và tất cả các bài kiểm tra bạn đã viết đều vượt qua, nhưng những bài kiểm tra khác phá vỡ, bản dựng vẫn bị hỏng. Thông thường, điều này có nghĩa là bạn đã đưa vào ứng dụng một lỗi hồi quy. Bạn có trách nhiệm - bởi vì bạn đã thực hiện thay đổi - sửa chữa tất cả các bài kiểm tra không đạt do các thay đổi của bạn. Trong bối cảnh của CI, điều này có vẻ hiển nhiên, nhưng thực ra nó không phải là một thực tế phổ biến trong nhiều dự án.

Có rất nhiều công cụ xây dựng có sẵn cho nhiều ngôn ngữ lập trình. Một số công cụ xây dựng phổ biến nhất bao gồmAnt for Java và MSBuild for .NET. Sử dụng công cụ tập lệnh được thiết kế đặc biệt để xây dựng phần mềm, thay vì một bộ tập lệnh shell hoặc tập lệnh lô tùy chỉnh, là cách hiệu quả nhất để phát triển một giải pháp xây dựng nhất quán, có thể lặp lại.

Vậy tại sao chúng ta cần một quá trình xây dựng để bắt đầu. Đối với người mới bắt đầu, đối với máy chủ Tích hợp liên tục, quá trình xây dựng phải dễ làm việc và phải liền mạch để thực hiện.

Hãy lấy một ví dụ đơn giản về việc tệp xây dựng có thể trông như thế nào đối với .Net -

<?xml version = "1.0" encoding = "utf-8"?>
<project xmlns = "http://schemas.microsoft.com/developer/msbuild/2003">
   <Target Name = "Build">
      <Message Text = "Building Project" />
      <MSBuild Projects = "project.csproj" Targets = "Build/>"
   </Target>
</project>

Các khía cạnh sau đây cần được lưu ý về đoạn mã trên:

  • Mục tiêu được chỉ định với tên của Bản dựng. Trong đó, mục tiêu là tập hợp các bước hợp lý cần được thực hiện trong một quy trình xây dựng. Bạn có thể có nhiều mục tiêu và có sự phụ thuộc giữa các mục tiêu.

  • Trong mục tiêu của chúng tôi, chúng tôi giữ một thông báo tùy chọn sẽ được hiển thị khi quá trình xây dựng bắt đầu.

  • Các MSBuild task được sử dụng để chỉ định dự án .Net nào cần được xây dựng.

Ví dụ trên là một trường hợp của một tệp xây dựng rất đơn giản. Trong Tích hợp liên tục, nó được đảm bảo rằng tệp này được cập nhật để đảm bảo rằng toàn bộ quá trình xây dựng là liền mạch.

Xây dựng giải pháp trong .Net

Công cụ xây dựng mặc định cho .Net là MSBuild và là thứ đi kèm với .Net framework. Tùy thuộc vào khuôn khổ trên hệ thống của bạn, bạn sẽ có sẵn phiên bản MSbuild phù hợp. Ví dụ: nếu bạn đã cài đặt .Net framework ở vị trí mặc định, bạn sẽ tìm thấyMSBuild.exe nộp ở vị trí sau -

C:\Windows\Microsoft.NET\Framework\v4.0.30319

Hãy xem cách chúng ta có thể xây dựng dự án mẫu của mình. Giả sử dự án mẫu của chúng tôi nằm trong một thư mục có tênC:\Demo\Simple.

Để sử dụng MSBuild để xây dựng giải pháp trên, chúng ta cần mở dấu nhắc lệnh và sử dụng tùy chọn MSBuild như trong chương trình sau.

msbuild C:\Demo\Simple\Simple.csproj

Trong ví dụ trên, csprojlà tệp dự án dành riêng cho .Net. Tệp csproj chứa tất cả các thông tin liên quan để đảm bảo rằng các thông tin cần thiết có sẵn để phần mềm xây dựng đúng cách. Sau đây là ảnh chụp màn hình đầu ra của lệnh MSBuild.

Bạn không cần phải lo lắng về các cảnh báo đầu ra miễn là Build thành công và không có lỗi.

Bây giờ chúng ta hãy xem xét các khía cạnh nhất định của tệp MSBuild để xem ý nghĩa của chúng. Những khía cạnh này rất quan trọng cần biết từ Chu kỳ tích hợp liên tục.

Tập lệnh xây dựng được sử dụng để xây dựng giải pháp sẽ là một phần của toàn bộ chu trình Tích hợp liên tục. Hãy xem tập lệnh xây dựng chung được tạo như một phần của Visual Studio trong.Netcho giải pháp mẫu của chúng tôi. Kịch bản xây dựng là một kịch bản khá lớn, ngay cả đối với một giải pháp đơn giản, vì vậy chúng ta sẽ đi qua các phần quan trọng nhất của nó. Theo mặc định, tập lệnh xây dựng sẽ được lưu trữ trong tệp có cùng tên với giải pháp chính trong Visual Studio. Vì vậy, trong trường hợp của chúng tôi, nếu bạn mở tệpSimple.csproj, bạn sẽ thấy tất cả các cài đặt sẽ được sử dụng để xây dựng giải pháp.

  • Phụ thuộc vào phiên bản MSBuild được sử dụng - Các cài đặt sau sẽ sử dụng các tệp MSBuild được cài đặt trên máy chủ CI.

<VisualStudioVersion Condition = "'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> <VSToolsPath Condition = "'$(VSToolsPath)' == ''"> 
   $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)
</VSToolsPath>

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

<Import Project = "$(MSBuildBinPath)\Microsoft.CSharp.targets" /> <Import Project = "$(VSToolsPath)\WebApplications\
   Microsoft.WebApplication.targets" Condition = "'$(VSToolsPath)' ! = ''" /> <Import Project = "$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\
   WebApplications\Microsoft.WebApplication.targets" Condition = "false" />

  • Những tệp nào được yêu cầu để xây dựng giải pháp đúng cách - ItemGroupthẻ sẽ chứa tất cả các tệp .Net cần thiết để dự án xây dựng thành công. Các tệp này sẽ cần phải nằm trên máy chủ xây dựng cho phù hợp.

<ItemGroup>
   <Reference Include = "Microsoft.CSharp" />
   <Reference Include = "System.Web.DynamicData" />
   <Reference Include = "System.Web.Entity" />
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />
   <Reference Include = "System" />
   <Reference Include = "System.Data" />
   <Reference Include = "System.Core" />
   <Reference Include = "System.Data.DataSetExtensions" />
   <Reference Include = "System.Web.Extensions" />
   <Reference Include = "System.Xml.Linq" />
   <Reference Include = "System.Drawing" />
   <Reference Include = "System.Web" />
   <Reference Include = "System.Xml" />
   <Reference Include = "System.Configuration" />
   <Reference Include = "System.Web.Services" />
   <Reference Include = "System.EnterpriseServices"/>
</ItemGroup>

  • Cài đặt máy chủ Web sẽ được sử dụng là gì - Khi chúng tôi truy cập chủ đề Triển khai liên tục, bạn sẽ thấy cách MSBuild sẽ được sử dụng để ghi đè các cài đặt này và triển khai nó đến máy chủ mà chúng tôi đã chọn.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>59495</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl></IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>

Bước quan trọng tiếp theo là đảm bảo rằng giải pháp xây dựng trên máy chủ xây dựng. Phần đầu tiên là bước thủ công, vì trước khi sử dụng công cụ tích hợp liên tục, trước tiên chúng ta phải đảm bảo rằng bản dựng được chạy trên máy chủ bản dựng theo cách giống như những gì đã được thực hiện trên máy khách. Để làm điều này, chúng ta phải thực hiện các bước sau:

Step 1- Sao chép toàn bộ tệp giải pháp lên máy chủ. Chúng tôi đã tạo một máy chủ phiên bản Amazon sẽ được sử dụng làm máy chủ xây dựng của chúng tôi. Vì vậy, hãy sao chép thủ công vào máy chủ của toàn bộ.Net giải pháp trên máy chủ.

Step 2- Đảm bảo rằng khung có mặt trên máy chủ. Nếu bạn đã biên dịch ứng dụng của mình trong .Net framework 4.0 trên máy khách của mình, bạn phải đảm bảo rằng nó cũng được cài đặt trên máy chủ. Vì vậy, hãy đến địa điểmC:\Windows\Microsoft.NET\Framework trên máy chủ của bạn và đảm bảo khuôn khổ mong muốn hiện diện.

Step 3 - Bây giờ chúng ta chỉ cần chạy MSBuild trên máy chủ và xem điều gì sẽ xảy ra.

Được rồi, có vẻ như chúng ta đã gặp lỗi. Có một bài học quan trọng trong Tích hợp liên tục và đó là bạn cần đảm bảo rằng Bản dựng hoạt động trên máy chủ bản dựng. Đối với điều này, bạn cần đảm bảo rằng tất cả phần mềm tiên quyết đã được cài đặt trên máy chủ bản dựng.

Đối với .Net, chúng ta cần cài đặt một thành phần có tên là Visual Studio Redistributable package. Gói này chứa tất cả các tệp cần thiết được yêu cầu cho một.Netứng dụng để xây dựng trên máy chủ. Vì vậy, chúng ta hãy thực hiện các bước cài đặt sau trên máy chủ xây dựng.

Step 4 - Nhấp đúp vào tệp thực thi để bắt đầu cài đặt.

Step 5 - Trong bước tiếp theo, đồng ý với Điều khoản cấp phép và nhấp vào Cài đặt.

Step 6 - Bây giờ khi chạy MSBuild, chúng ta cần đảm bảo rằng chúng ta bao gồm một tham số bổ sung khi gọi MSBuild là - p:VisualStudioversion = 12.0. Điều này đảm bảo rằng MSBuild tham chiếu đến những tệp đã được tải xuống ở bước trước đó.

Bây giờ chúng tôi có thể thấy rằng giải pháp đã được xây dựng đúng cách và chúng tôi cũng biết dự án cơ sở của chúng tôi xây dựng chính xác trên máy chủ.

Khía cạnh quan trọng tiếp theo là đảm bảo mã cơ sở của chúng tôi được kiểm tra trong máy chủ quản lý kho lưu trữ mã nguồn của chúng tôi là Git. Để làm điều này, chúng ta cần làm theo các bước sau.

Step 1- Khởi tạo kho lưu trữ để có thể tải lên Git. Điều này được thực hiện vớigitlệnh init. Vì vậy, bạn cần phải chuyển đến thư mục dự án của mình và phát hànhgit init chỉ huy.

Step 2- Bước tiếp theo được gọi là dàn tệp trong Git. Điều này chuẩn bị tất cả các tệp trong thư mục dự án, cần được thêm vào Git. Bạn làm điều này vớigit addnhư được hiển thị trong ảnh chụp màn hình sau. Các '.' ký hiệu được sử dụng để nói rằng tất cả các tệp trong thư mục và thư mục con phải được bao gồm trong cam kết.

Step 3 - Bước cuối cùng là cam kết các tệp vào kho lưu trữ Git, để bây giờ nó là một kho lưu trữ Git chính thức.

Bây giờ chúng ta đã có mã nguồn của mình trong kho lưu trữ Git và tất cả mã ban đầu của chúng ta đều hoạt động trên máy chủ xây dựng, đã đến lúc tạo một dự án trong máy chủ Tích hợp liên tục của chúng ta. Điều này có thể được thực hiện qua các bước sau:

Step 1- Đăng nhập vào phần mềm TeamCity. Đi tới url trên máy chủ Tích hợp liên tục của bạn -http://localhost:8080/login.html.

Nhập thông tin đăng nhập quản trị và đăng nhập vào máy chủ.

Step 2- Sau khi đăng nhập, bạn sẽ thấy màn hình chính. Nhấp chuộtCreate Project để bắt đầu một dự án mới.

Step 3- Đặt tên cho dự án và nhấn Create để bắt đầu dự án. Trong trường hợp của chúng tôi, chúng tôi đang đặt tên là 'Demo' cho dự án của chúng tôi như thể hiện trong ảnh chụp màn hình sau.

Step 4- Bước tiếp theo là đề cập đến kho lưu trữ Git sẽ được sử dụng trong dự án của chúng ta. Hãy nhớ rằng trong môi trường Tích hợp liên tục, máy chủ CI cần lấy mã từ kho lưu trữ hỗ trợ Git. Chúng tôi đã kích hoạt thư mục dự án của mình thành một kho lưu trữ hỗ trợ Git ở bước trước đó. Trong TeamCity, bạn cần tạo một VCS root. Đối với điều này, hãy nhấp vàoVCS Roots trong màn hình chính của dự án.

Step 5 - Trong màn hình xuất hiện tiếp theo, nhấp vào Create VCS root như thể hiện trong ảnh chụp màn hình sau.

Step 6 - Trong màn hình tiếp theo xuất hiện, thực hiện các bước sau:

  • Đề cập đến loại VCS là Git.

  • Đặt tên cho gốc VCS, đây có thể là bất kỳ tên thân thiện nào. Chúng tôi đã đặt tên làApp.

  • Cung cấp url Tìm nạp là C:\Demo\Simple - Đây là out git kho lưu trữ được kích hoạt.

  • Nếu bạn cuộn màn hình xuống, bạn sẽ thấy nút Kiểm tra kết nối. Nhấp vào nó để đảm bảo rằng bạn có thể kết nối thành công với kho lưu trữ hỗ trợ Git.

Step 7 - Nhấp vào Tạo và bây giờ bạn sẽ thấy kho lưu trữ của bạn đã được đăng ký như thể hiện trong hình sau.

Step 8- Bước tiếp theo là tạo cấu hình xây dựng sẽ được sử dụng để xây dựng dự án. Chuyển đến màn hình dự án của bạn trongTeamCity → General Settings. Nhấp vào Tạo cấu hình bản dựng.

Step 9- Trong màn hình sau, đặt tên cho Cấu hình xây dựng. Trong trường hợp của chúng tôi, chúng tôi đã đặt tên nó làDemoBuild và sau đó nhấp vào Tạo.

Step 10 - Trong màn hình tiếp theo xuất hiện, bạn sẽ được yêu cầu chọn VCS repositoryđã được tạo trong các bước trước đó. Vì vậy, hãy chọn tên‘App’ và nhấp vào Đính kèm.

Step 11- Bây giờ trong màn hình tiếp theo bật lên, chúng ta cần cấu hình các bước xây dựng. Vì vậy, hãy nhấp vào 'configure build steps manually'siêu liên kết.

Step 12 - Trong màn hình xây dựng tiếp theo, chúng ta cần nhập các chi tiết sau:

  • Chọn loại Runner là MSBuild.

  • Đặt tên tùy chọn cho tên bước.

  • Cung cấp tên của tệp cần được xây dựng. Khi chúng tôi chỉ định MSbuild trong các phần trước, chúng tôi thường thấy rằng chúng tôi cung cấp tùy chọnSimple.csproj. Điều tương tự cũng cần được chỉ rõ ở đây.

  • Chọn phiên bản MSBuild là 'Microsoft Build Tools 2013'.

  • Chọn MSBuild ToolsVersion như 12.0.

  • Cuộn xuống trang để Lưu cài đặt.

Step 13 - Trong màn hình tiếp theo, nhấp vào Chạy.

Bạn sẽ thấy quá trình xây dựng ứng dụng của mình đang được tiến hành.

Bạn sẽ nhận được một màn hình thành công, đó là một dấu hiệu tốt cho thấy giải pháp của bạn đang được xây dựng đúng cách.

Bạn cũng có thể truy cập nhật ký xây dựng của mình để xem tất cả các bước được trình bày bởi máy chủ Tích hợp liên tục như được hiển thị trong ảnh chụp màn hình sau.

Bây giờ chúng ta đã có mã cơ sở của mình trong Git và liên kết đến máy chủ Tích hợp liên tục, cuối cùng đã đến lúc chúng ta thấy bước đầu tiên của Tích hợp liên tục hoạt động. Điều này được thực hiện bằng cách xác định các tác vụ trong máy chủ Tích hợp Liên tục, chẳng hạn như các trình kích hoạt, giúp toàn bộ Quy trình Tích hợp Liên tục trở nên liền mạch nhất có thể. Hãy thay đổi mã của chúng tôi trong Visual Studio.

Step 1 - Đi đến Demo.aspx trang trong Visual Studio và thực hiện thay đổi đối với tiêu đề của trang.

Step 2 - Nếu chúng tôi truy vấn kho lưu trữ Git của mình thông qua git status trên thực tế, bạn sẽ thấy rằng Demo.aspx tệp đã được sửa đổi.

Bây giờ chúng tôi cần đảm bảo rằng mọi thay đổi trong mã của chúng tôi sẽ kích hoạt một bản dựng trong máy chủ tích hợp liên tục của chúng tôi. Đối với điều này, chúng tôi cần thực hiện các thay đổi sau.

Step 3 - Chuyển đến bảng điều khiển dự án của bạn và nhấp vào phần trình kích hoạt và nhấp vào Add new trigger.

Step 4 - Trong màn hình tiếp theo xuất hiện, hãy chọn VCS trigger, sẽ được sử dụng để tạo trình kích hoạt để khi đăng ký vào kho lưu trữ, một bản dựng sẽ được kích hoạt.

Step 5 - Bấm Show Advanced Options và đảm bảo các tùy chọn hiển thị trong ảnh chụp màn hình sau được chọn.

Step 6- Nhấp vào Lưu. Bây giờ bạn sẽ thấy trình kích hoạt được đăng ký thành công như được hiển thị trong ảnh chụp màn hình sau.

Step 7- Bây giờ đã đến lúc kiểm tra mã của chúng tôi vào kho lưu trữ Git và xem điều gì sẽ xảy ra. Vì vậy, chúng ta hãy đi đến dấu nhắc lệnh của chúng tôi và đưa ragit add lệnh để phân giai đoạn các tệp đã thay đổi của chúng tôi.

Step 8 - Bây giờ phát hành git commit và nó sẽ đẩy các thay đổi vào kho lưu trữ Git.

Step 9 - Nếu bây giờ bạn chuyển đến màn hình Tổng quan về dự án, bây giờ bạn sẽ thấy một bản dựng mới sẽ được kích hoạt và chạy.

Nếu bạn thấy Change log Tab, bạn sẽ thấy git comment mà đã kích hoạt xây dựng.

Hãy thử nó một lần nữa. Hãy thực hiện một thay đổi khác đối vớiDemo.aspxtập tin. Hãy thực hiện mộtgit add lệnh và một git commit lệnh với thông báo cam kết sau.

Bây giờ bạn sẽ thấy một công trình được tự động kích hoạt trong bảng điều khiển Dự án trong TeamCity.

Bản dựng sẽ hiển thị thông báo thành công.

Bây giờ bạn sẽ thấy thông báo 'Cam kết thứ hai' được sử dụng khi thay đổi được cam kết với git repository.

Hiện chúng tôi đã hoàn thành thành công phần đầu tiên của quá trình Tích hợp liên tục.

Thông báo lỗi bản dựng là một sự kiện được kích hoạt bất cứ khi nào bản dựng bị lỗi. Thông báo được gửi đến tất cả những người chủ chốt bất cứ khi nào bản dựng không thành công. Điều quan trọng đầu tiên cần làm trong trường hợp này là đảm bảo dành thời gian cho bản dựng bị lỗi để đảm bảo bản dựng được thông qua. Các bước sau được sử dụng để đảm bảo rằng các thông báo xây dựng được đưa vào TeamCity.

Sau đây là các bước để thiết lập email thông báo trong TeamCity.

Step 1- Trong TeamCity, đi tới bảng điều khiển Dự án của bạn, nhấp vào Quản trị ở góc trên cùng bên phải. Sau đó, bạn sẽ thấyEmail Notifierliên kết ở phía bên tay trái. Nhấp vào liên kết này để hiển thị cài đặt chung cho Email.

Step 2 - Bước tiếp theo là nhập các chi tiết của một hợp lệ SMTP Server. Gmail cung cấp một tiện ích SMTP miễn phí, bất kỳ ai cũng có thể sử dụng được. Vì vậy, chúng tôi có thể nhập các chi tiết đó trong màn hình tiếp theo xuất hiện như trong ảnh chụp màn hình sau.

  • Máy chủ SMTP - smtp.gmail.com
  • Cổng SMTP số - 465
  • Gửi email từ và đăng nhập SMTP - Đây phải là một id Gmail hợp lệ
  • Mật khẩu SMTP - Mật khẩu hợp lệ cho id Gmail đó
  • Kết nối an toàn - Đặt đây là SSL

Step 3 - Bấm Test Connectionchỉ để đảm bảo rằng các cài đặt đang hoạt động bình thường. Sau đó nhấp vàoSave để lưu cài đặt.

Step 4- Bước tiếp theo là bật thông báo bản dựng cho người dùng. Nhiệm vụ đầu tiên là tạo một người dùng sẽ nhận được các thông báo về bản dựng này. Đi tới bảng điều khiển dự án của bạn và chọnUsers Option.

Step 5- Tạo một người dùng mới. Nhập tên người dùng và mật khẩu được yêu cầu. Sau đó nhấp vào nút Tạo người dùng, nút này sẽ nằm ở cuối màn hình.

Step 6 - Bây giờ đăng nhập vào hệ thống TeamCity với id người dùng và mật khẩu mới này.

Step 7- Sau khi đăng nhập, bạn sẽ thấy phần Cài đặt chung của người dùng. Trong phần Trình thông báo Email, nhấp vào Chỉnh sửa.

Step 8 - Trong màn hình tiếp theo xuất hiện, hãy nhấp vào Add new rule.

Step 9 - Trong Thêm quy tắc mới, chọn hai tùy chọn sau rồi nhấp vào Lưu.

  • Bản dựng từ các dự án được chọn - Chọn dự án Demo.

  • Bật hộp kiểm cho 'Bản dựng không thành công'.

Bằng cách bật hai tùy chọn này, bây giờ bất cứ khi nào bản dựng không thành công cho dự án Demo, một thông báo qua email sẽ được gửi đến người dùng - demouser.

Step 10- Bây giờ hãy kích hoạt một bản dựng sai để xem điều này đang hoạt động. Trong Visual Studio, đi tớidemo.aspx.cs và thêm một dòng mã sai.

Step 11 - Bây giờ đăng ký mã từ Git bằng cách thực hiện git add và git commit.

Bây giờ trong Bảng điều khiển dự án, bản dựng sẽ tự động được kích hoạt và bạn sẽ thấy rằng bản dựng sẽ không thành công như thể hiện trong ảnh chụp màn hình sau.

Nếu bạn đăng nhập vào id Gmail của demouser, bạn sẽ thực sự thấy thông báo lỗi xây dựng trong đó như được hiển thị trong ảnh chụp màn hình sau.

Một trong những khía cạnh quan trọng của Tích hợp liên tục là luôn xem các bản dựng đang hoạt động như thế nào, thu thập các chỉ số quan trọng, ghi lại các kết quả đó và tạo phản hồi liên tục thông qua các bản dựng liên tục.

Lợi ích của việc áp dụng các chỉ số này là gì?

  • Not Committing Code Enough- Nếu các nhà phát triển không cam kết mã cho kho lưu trữ kiểm soát phiên bản thường xuyên, thì lý do có thể là do quá trình tích hợp chậm. Để bắt đầu giảm thời lượng xây dựng, hãy thực hiện phân tích cấp cao về môi trường xây dựng tích hợp để xác định các điểm nghẽn.

    Tiếp theo, phân tích các phát hiện và xác định cải tiến phù hợp nhất, sau đó cố gắng thực hiện các thay đổi trong quá trình xây dựng để giảm thời lượng của quá trình xây dựng. Cuối cùng, hãy đánh giá lại thời lượng xây dựng để xác định xem có đảm bảo các cải tiến tiếp theo hay không.

  • Improve Test Performance- Ngay cả trong một hệ thống CI hoạt động tốt, phần lớn thời gian xây dựng tích hợp sẽ được thực hiện bởi các thử nghiệm tự động. Đánh giá và cải thiện hiệu suất của các thử nghiệm này có thể giảm đáng kể thời lượng xây dựng.

  • Infrastructure Issues − You may discover that integration builds are slow because of the system infrastructure. Perhaps network performance is slow or there is a slow-performing virtual private network connection.

    Geographically dispersed systems and unreliable hardware or software can also induce performance issues. Investigate and improve any infrastructure resources to reduce the build duration.

Metrics

Following are some of the metrics which are available in a Continuous Integration server.

Let’s look at what TeamCity has to offer −

One of the simplest form of metrics is what is available in the project dashboard. The key element here is to note the duration of each build. If the duration of each build starts increasing disproportionally to the code being built, then this could be an issue. So, this is one feedback that can be taken and the causes of this could be that the CI server is low on resources and maybe the capacity of the server needs to be increased.

TeamCity has the facility to see if the CI server is in fact having any sort of issues with regards to infrastructure. In the admin dashboard in TeamCity, one can click on Disk Usage to see how much disk space is being consumed by each build.

If any more details are required, then TeamCity has the diagnostics button, which can give more information on the CPU and Memory being utilized by the CI Server.

Detailed View of Build Metrics

If one wants to see a detailed view of the builds of a particular project over time, then this is available as a part of the project builds. In the Project build screen, go to the Statistics screen, this will provide various statistics and charts on how the build is performing.

One of the key features of Continuous Integration is to ensure that the on-going testing holds all the code which gets built by the CI server. After a build is carried out by the CI Server, it has to be ensured that the test cases are in place to get the required code tested. Every CI server has the ability to run unit test cases as part of the CI suite. In .Net, the unit testing is a feature which is inbuilt into the .Net framework and the same thing can be incorporated into the CI Server as well.

This chapter will see how we can define a test case in .Net and then let our TeamCity server run this test case after the build is completed. For this, we first need to ensure that we have a unit test defined for our sample project.

To do this, we must follow the ensuing steps with utmost carefulness.

Step 1 − Let’s add a new class to our solution, which will be used in our Unit Test. This class will have a name variable, which will hold the string “Continuous Integration”. This string will be displayed on the web page. Right-click on the Simple Project and choose the menu option Add → Class.

Step 2 − Give a name for the class as Tutorial.cs and click the Add button at the bottom of the screen.

Step 3 − Open the Tutorial.cs file and add the following code in it. This code just creates a string called Name, and in the Constructor assign the name to a string value as Continuous Integration.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      public Tutorial() {
         Name = "Continuous Integration";
      }
   }
}

Step 4 − Let us make the change to our Demo.aspx.cs file to use this new class. Update the code in this file with the following code. So this code will now create a new instance of the class created above.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      protected void Page_Load(object sender, EventArgs e) {
         tp.Name = "Continuous Integration";
      }
   }
}

Step 5 − In our demo.aspx file, let us now reference the tp.Name variable, which was created in the aspx.cs file.

<%@ Page Language = "C#" AutoEventWireup = "true" 
   CodeBehind = "Demo.aspx.cs" Inherits = "Simple.Demo" %>
<!DOCTYPE html>
<html xmlns = "http://www.w3.org/1999/xhtml">
   
   <head runat = "server">
      <title>TutorialsPoint1</title>
   </head>
   
   <body>
      <form id = "form1" runat = "server">
         <div>
            <% = tp.Name%>)
         </div>
      </form>
   </body>
   
</html>

Just to ensure our code works fine with these changes, you can run the code in Visual Studio. You should get the following output once the compilation is complete.

Step 6 − Now it is time to add our Unit tests to the project. Right-click on Solution and choose the menu option Add → New Project.

Step 7 − Navigate to Test and on the right hand side, choose Unit Test Project. Give a name as DemoTest and then click OK.

Step 8 − In your Demo Test project, you need to add a reference to the Simple project and to the necessary testing assemblies. Right-click on the project and choose the menu option Add Reference.

Step 9 − In the next screen that comes up, go to Projects, choose Simple Reference and click OK.

Step 10 − Click Add Reference again, go to Assemblies and type Web in the Search box. Then add a reference of System.Web.

Step 11 − In the Unit Test file, add the following code. This code will ensure that the Tutorial class has a string name variable. It will also assert the fact that the Name should equal a value of “Continuous Integration”. This will be our simple Test case.

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Simple;

namespace DemoTest {
   [TestClass]
   public class UnitTest1 {
      [TestMethod]
      public void TestMethod1() {
         Tutorial tp = new Tutorial();
         Assert.AreEqual(tp.Name, "Continuous Integration");
      }
   }
}

Step 12 − Now let’s run our test in Visual Studio to make sure it works. In Visual Studio, choose the menu option Test → Run → All Tests.

After running the test, you will see the Test successfully run on the left hand side of Visual Studio.

Enabling Continuous Testing within TeamCity – Now that all the test cases are in place, it is time to integrate these into our Team City server.

Step 13 − For this, we need to create a build step in our Project configuration. Go to your project home and click Edit Configuration Settings.

step 14 − Then go to Build Step → MS Build and click Add build step as depicted in the following screenshot.

In the next screen that comes up, add the following values −

  • Choose the runner type as Visual Studio Tests.

  • Enter an optional Test step name.

  • Choose the Test Engine type as VSTest.

  • Choose the Test Engine version as VSTest2013.

  • In the Test files name, provide the location as DemoTest\bin\Debug\DemoTest.dll – Remember that DemoTest is the name of our project which contains our Unit Tests. The DemoTest.dll will be generated by our first build step.

  • Click Save which will be available at the end of the screen.

Now you will have 2 build steps for your project. The first is the Build step which will build your application code and your test project. And the next will be used to run your test cases.

Step 15 − Now it is time to check-in all your code in Git, so that the entire build process can be triggered. The only difference is this time, you need to run the git add and git commit command from the Demo parent folder as shown in the following screenshot.

Now when the build is triggered, you will see an initial output which will say that the test passed.

Step 16 − If you click on the Test passed result and go to the Test tab, you will now see that the UnitTest1 was executed and that it is passed.

Continuous Inspection is the process of an automated code review of inspection conducted for your code before the actual tests are run. There are subtle differences between inspecting and testing software. Testing is dynamic and executes the software in order to test the functionality. Inspection analyzes the code based on a set of predefined rules.

Inspectors (or static and dynamic analysis tools) are directed by identified standards that teams should adhere to (usually coding or design metrics). Examples of inspection targets include coding “grammar” standards, architectural layering adherence, code duplication, and many others.

Continuous Inspection reduces the time between a discovery and a fix. There are a number of Continuous Inspection tools available. For this example, we are going to be using NCover 3.x which has an integration with TeamCity. Let’s see how we can carry out Continuous Inspection and what it can do for us.

Download and Install NCover

NCover is a separate product which needs to be downloaded and installed. To Download NCover, please click on the following link and download the 32-bit installer − http://www.ncover.com/info/download.

Run the downloaded installer and then click Next after the installer is started.

Accept the License agreement and then click Next.

Accept the default components and click Next.

Click on the Install button to begin the installation.

Click the Finish button to complete the installation.

Launch the NCover installation for the first time by going to C:\Program Files (x86)\NCover\ NCover.Explorer.exe. You will just need to install a trial key for the first time, which is a straightforward process.

Configure the Project in TeamCity to Use NCover

Step 1 − Go to your project home screen and click Edit Configuration Settings.

Step 2 − Go to Build Steps and click Edit for the TestStep. Continuous Inspection needs to run along with the Unit tests which are defined.

Step 3 − In the .Net Coverage section, click on .Net Coverage Tool. And then choose the following settings.

  • Choose the .Net Coverage tool as NCover(3.x)
  • Platform as x86
  • Version as v4.0
  • Path to NCover as C:\Program Files (x86)\NCover
  • Leave the other settings as they are

Step 4 − Click Save.

Step 5 − Now go to the main screen of your project and click Run.

Step 6 − Once the build is run, click on the Test passed. You will now see a Code Coverage screen and you will see many metric indicators.

Step 7 − You can now click the Code Coverage tab to get more information on the Code Analysis.

Step 8 − Click the fullcoveragereport.html. You will now get a full comprehensive report on the inspection carried out for the .Net code.

Continuous Database Integration is the process of rebuilding your database and test data any time a change is applied to a project’s version control repository.

In Database Integration, generally all the artifacts related to the database integration −

  • Should reside in a version control system.
  • Can be tested for rigor and inspected for policy compliance.
  • Can be generated using your build scripts.

Activities that can be involved in Continuous Database Integration can be any one of the following −

Drop a Database − Drop the database and remove the associated data, so that you can create a new database with the same name

Create a new Database − Create a new database using Data Definition Language (DDL).

Insert the Initial Data − Insert any initial data (e.g., lookup tables) that your system is expected to contain when delivered.

Migrate Database and Data − Migrate the database schema and data on a periodic basis (if you are creating a system based on an existing database).

Modify Column Attributes − Modify table column attributes and constraints based on requirements and refactoring.

Modify Test Data − Alter test data as needed for multiple environments.

So in our Continuous Database example, we are going to do the following steps −

  • We will create a MS SQL Server database and a corresponding table.

  • We will create a script out of SQL Server Management Studio. This database script will be used to set up our table in the database.

  • We will write a code in our ASP.Net project to access this database.

  • We will create a step in our project in TeamCity to run this script.

  • We will check in our script into Git.

Steps to do this in the AWS database which was created in an earlier section.

Step 1 − Create an MS SQL Server database and a corresponding table. Let’s open SQL Server Management Studio and create a simple database and table. Right-click databases and click on New Database.

Step 2 − Name it as Demodb and click OK

Step 3 − In the new database, right-click and create a new table.

Step 4 − You can add your desired columns to the table.

Step 5 − Save the table and name it as Demotb.

Step 6 − Now right-click on the table and choose the menu option Script Table as → Drop and Create to → File.

Step 7 − Save the file to the demo project folder as Sample.sql.

This is what the database script would look like. It would first drop an existing table if present and then re-create the table.

USE [Demodb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******

DROP TABLE [dbo].[Demotb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Demotb](
   [TutorialName] [nvarchar](max) NULL,
   [TutorialID] [smallint] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

Step 8 − Now let’s quickly change our ASP.Net code to refer to the new database.

Step 9 − In the Tutorial.cs file in your Demo project, add the following lines of code. These lines of code will connect to your database, take the Server version and store the version name in the Name variable. We can display this Name variable in our Demo.aspx.cs file through a Response.write command.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      
      public Tutorial() {
         string connectionString = "Data Source = WIN-50GP30FGO75;
         Initial Catalog = Demodb;
         Integrated Security = true;";
         
         using (SqlConnection connection = new SqlConnection()) {
            connection.ConnectionString = connectionString;
            connection.Open();
            Name = connection.ServerVersion;
            connection.Close();
         }
      }
   }
}

Step 10 − Add the following code to the Demo.aspx.cs file to ensure that it displays the SQL Server version.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      
      protected void Page_Load(object sender, EventArgs e){
         Response.Write(tp.Name);
      }
   }
}

Now if we run the code, you will get the following output in the browser.

Step 11 − Now let us add our step in TeamCity which will invoke the database script. Go to your project dashboard and click Edit Configuration Settings.

Step 12 − Go to Build Steps and click Add build step.

Choose the following options (Note that MS SQL Server client should be installed on the CI Server).

  • Runner type should be the Command Line.

  • Give an optional Step Name.

  • Run should be Executable with parameters.

  • Command executable should be C:\Program Files\Microsoft SQL Server\110\Tools\Binn\sqlcmd.exe

  • Command parameters should be -S WIN-50GP30FGO75 -i Sample.sql. Where –S gives the name of the SQL Server instance.

Step 13 − Click Save.

Now what needs to be ensured is the build order. You have to ensure the build order is as follows.

Step 14 − You can change the build order by choosing the option to reorder build steps.

  • The database setup should be first – So this will be used to recreate your database from fresh.

  • Next is the build of your application.

  • Finally your test setup.

Step 15 − Now run the git add and git commit command so that the Sample.sql file is checked into Git. This will trigger a build automatically. And this build should pass.

You now have a full-fledged build cycle with a continuous database integration aspect as well in your cycle. In the next section, let’s take this further and look at Continuous Deployment.

Now that you have done this with a local SQL Server, we can repeat the same steps for a AWS MS SQL Server which was created in one of the earlier sections. To connect to a Microsoft SQL Server, you need to connect via the following convention.

Step 16 − First see what is the name assigned to your database instance in AWS. When you log-in to the AWS, go to the RDS section under the database section.

Step 17 − Click on DB Instances in the next screen that comes up.

step 18 − Click on your database and make a note of the endpoint. In the following screenshot, it is demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com:1433

Step 19 − Now to connect to the database from SQL Server Management Studio, you need to specify the connection as demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com,1433 (Note the comma used between instance name and port no).

The following screenshot shows a successful connection to the database.

Then you can repeat all the same steps. The Sqlcmd command will be as follows −

This same command can be replaced in the Database build step in TeamCity. When you execute the sqlcmd command, the table will be created automatically in your SQL Server database in AWS.

Automated builds and repeatable builds. Automated tests and repeatable tests. Test categories and test frequencies. Continuous inspections. Continuous database integration. These string of tasks in creating an effective CI environment primarily enables one key benefit: releasing working software at any point in time, in any environment.

In our previous chapters, we have accomplished all of the following segments −

  • Created our code.
  • Ensured a proper build in TeamCity.
  • Created a Database Integration process.
  • Conducted successful testing.

Now the only thing remaining is to carry out an automated deployment, so that our entire process is complete.

For an automated deployment in our case, we need to follow these steps −

  • In our deployment server, ensure that IIS is installed.

  • Ensure that IIS user is given access to our database.

  • Create a publish profile which will be used to publish the site when it is built.

  • Ensure we change our MSBuild command to do an automatic deployment.

  • Automate TeamCity to do an automatic publish.

  • Do a git commit to ensure all your files are in Git.

Step 1 − Configure a local IIS Server. If you have a local or remote IIS Server, the following configuration can be carried out to deploy our application. It’s always a good practice to see if a deployment can be done manually before it is done in an automated fashion.

Step 2 − On a Windows 2012 server, go to your Server Manager and click on Add Roles and Features.

Step 3 − Click Next on the following screen that comes up.

Step 4 − Choose roles-based or feature-based installation on the next screen and click Next.

Step 5 − Select the default server and click Next.

Step 6 − Choose the Web server role and click Next.

Step 7 − In the next screen that comes up, click Next.

Step 8 − Click Next again on the following screen that appears.

Step 9 − In the next screen that pops up, click Next.

Step 10 − In the final screen, you can click the Install button to install the IIS.

Once you have IIS installed, you can open it by opening the Internet Information Services.

Step 11 − Click Application Pools, you will see a pool with the name of DefaultAppPool. This needs to have access to SQL Server in the next step.

Step 12 − If we need to connect a ASP.Net application to a MS SQL Server application, we have to give access to the default application pool to the SQL Server instance, so that it can connect to our Demodb database.

Step 13 − Open SQL Server Management Studio. Go to Logins, right-click and choose the menu option New Login.

In the next screen, update the following parameters and click OK.

  • Login name as IIS APPPOOL\DefaultAppPool.
  • Default database – This should be our database, which is demodb.

Step 14 − Creating a Publish Profile. The publish profile is used in Visual Studio to create a deployment package that can then be used with MS Build and in any CI Server accordingly. To do this, from Visual Studio, right-click on the project and click the menu option of Publish

Step 15 − In the next screen that comes up, choose to create a new Publish profile, give it a name – DemoDeployment. Then click the Next button.

In the ensuing screen that shows up, add the following values −

  • Choose the Publish method as Web Deploy.
  • Enter the server as localhost.
  • Enter the site name as Default Web Site/Demo.
  • Put the destination url as http://localhost/Demo

Then click the Next button.

Step 16 − In the next screen, click Next.

Step 17 − In the final screen that comes up, click the Publish button.

Now if you go to the C:\Demo\Simple\Properties\PublishProfiles location of your project, you will see a new publish profile xml file created. This publish profile file will have all the details required to publish your application to the local IIS server.

Step 18 − Now let’s customize our MSBuild command and use the above publish profile and see what happens. In our MSBuild command, we specify the following parameters −

  • Deploy on Build is true – this will trigger an automatic deployment once a successful build is done.

  • We are then mentioning to use the Publish profile which was used in the above step.

  • The Visual Studio version is just to be mentioned to the MSBuild deployment capability on what is the version of the Visual Studio being used.

When you run the above command, MSBuild will trigger a build and deployment process. What you will note that, it is deploying it to our Default Website in our IIS Server.

Now if we browse to the site – http://localhost/Demo/Demo.aspx we will see the following output, which means that the MSBuild did a successful deployment to our website.

Step 19 − Automating through TeamCity – Now it is time to add a task to our TeamCity server to automatically use MSBuild to deploy our application, based on the above mentioned steps.

Step 20 − Go to your project dashboard and click Edit Configuration Settings.

Step 21 − Go to Build Steps and click Add a Build step.

Choose the following options −

  • The runner type should be MSBuild

  • Give an optional Step name

  • Enter the build path as Simple/Simple.csproj

  • Keep the MSBuild version as Microsoft Build Tools 2013

  • Keep the MSBuild Toolsversion as 12.0

  • Put the command line as /p:DeployOnBuild = true /p:PublishProfile = DemoDeployement /p:VisualStudioVersion = 12.0

Step 22 − Click Save.

Make sure that in the build steps, the Deploy step is the last step in the chain.

Step 23 − Now let’s do a final git commit, to ensure all the files are in Git and can be used by TeamCity.

Congratulations, you have successfully set up a complete Continuous Integration Cycle for your application, which can be run at any point in time.

Let’s have a final review of the best practices of Continuous Integration based on all the lessons we have learnt so far −

  • Maintain a code repository − This is the most basic step. In all our examples, everything is maintained in a Git repository right from the code base to the Publish profiles, to the database scripts. It must always be ensured that everything is kept in the code repository.

  • Automate the build − We have seen how to use MSBuild to automate a build along with using a publish profile. This is again a key step in the continuous Integration process.

  • Make the build self-testing − Ensure that you can test the build by keeping unit test cases in place and these test cases should be in such a way that it can be run by the Continuous Integration server.

  • Everyone commits to the baseline every day − This is a key principle of Continuous Integration. There is no point staying till the end of the entire process to see who breaks the build.

  • Every commit (to baseline) should be built − Every commit made to the application, needs to be successfully built. If the build fails for whatever reason, then the code needs to be changed to ensure the build passes.

  • Keep the build fast − If the build is slow, then it would indicate a problem in the entire Continuous Integration process. Ensure that the builds are always limited to a duration, preferably should never go beyond 10 minutes.

  • Everyone can see the results of the latest build − The TeamCity dashboard gives everyone a view of all the builds, which have either passed or failed. This gives a good insight to all the people who are involved in the Continuous Integration process.

ja/tutorial
es/tutorial
de/tutorial
fr/tutorial
th/tutorial
pt/tutorial
ru/tutorial
vi/tutorial
it/tutorial
ko/tutorial
tr/tutorial
id/tutorial
pl/tutorial
hi/tutorial
japost
espost
depost
frpost
thpost
ptpost
rupost
vipost
itpost
kopost
trpost
idpost
plpost
hipost

© Copyright 2021 - 2024 | All Rights Reserved