Configuration thành công – CI: định danh này vào QLCH là tên thường gọi của các sản phẩm, sản phẩm trung gian, một tập tin (file) hoặc nhóm file, tài liệu hoặc đội tài liệu vào một dự án công trình mà ta đề xuất phải cai quản và kiểm soát. Nói tầm thường là rất nhiều “món” được tạo thành trong một dự án công trình mà ta cần phải quản lý, ví dụ: một file source code, tư liệu về yêu ước sản phẩm, bạn dạng thiết kế v.v.Baseline: một điểm “mốc” được thỏa thuận hợp tác bởi những người dân liên quan trong một dự án, làm sao cho sau điểm “mốc” này, mọi chuyển đổi phải được thông tin tới toàn bộ những người dân có liên quan.

Bạn đang xem: Quản lý cấu hình phần mềm


Một giải pháp tổng quan, QLCH bao hàm các nhóm vận động như hình 2.

Lập planer QLCH (Configuration Management planning)

Thông thường, việc lập planer cho QLCH được diễn tả trong tài liệu mang tên Kế hoạch cai quản cấu hình (Configuration Manegement Plan – CMP). Bạn dạng kế hoạch này thường bao gồm:


Ý nghĩa, mục tiêu và phạm vi áp dụng của phiên bản kế hoạch
Vai trò và nhiệm vụ của nhóm, cá thể trong dự án triển khai các vận động khác nhau tương quan đến QLCH. Định nghĩa cụ thể ai thực hiện (perform), ai chú ý (review), ai phê chuẩn y (approve) trên các CI của dự án, cũng tương tự vai trò của khách hàng, người tiêu dùng đầu cuối. Coi ví dụ sống hình 3.Công nỗ lực (tool), môi trường thiên nhiên (environment) và cơ sở hạ tầng (infrastructure). Phần này tế bào tả các công cụ ứng dụng hoặc quy trình giấy tờ thủ tục được sử dụng cung cấp QLCH, ví dụ điển hình công cụ cai quản phiên bạn dạng sản phẩm (version control); diễn đạt vị trí các máy chủ, sản phẩm trạm, cấu hình hệ thống client-server,…Phương pháp định danh và thiết lập baseline trên những CIQuy cầu đặt tên trong dự án, tất cả cả thương hiệu file
Quy trình giải pháp xử lý và làm chủ các biến đổi (change control process)Chỉ định thành viên đội Configuration Control Board (CCB)Thông tin vị trí lưu trữ các CIKiểm kê và report cấu hình (configuration accounting và reporting)Quy trình thủ tục lưu trữ với chép dự trữ (backup and archieve)

Các điểm trong phiên bản kế hoạch trên đã được giải thích rõ trong số phần tiếp sau.

Định danh/đánh số các CI (Identification of Configuration Items)

Định danh là 1 trong những chuyển động nền tảng của QLCH. Mục đích của định danh là để xác định tính tốt nhất của một CI, cũng giống như mối quan liêu hệ của nó với những CI khác. Nó bao hàm việc mô tả tên, tiến công số, khắc ghi đặc trưng, giúp nhận biết và tách biệt một CI với các CI tuyệt thành phần khác.

Bạn có thể nhận thấy bề ngoài định danh tựa như trong cuộc sống thực tế. Ví dụ, fan ta viết số bàn trong nhà hàng quán ăn nhằm góp người giao hàng mang đúng thức ăn uống cho khách.

Trong chế tạo phần mềm, một CI có thể gồm 1 hay những file. Ví dụ: một module thương hiệu Exp
Mod hoàn toàn có thể được xem như là một CI, module này có 2 tệp tin Exp
Mod.h và Exp
Mod.c.

Mỗi CI cần có một trong những định danh duy nhất, dạng thức thường trông thấy là:

Ví dụ: PRJ001_REQB_1.0.4_draft_B mang lại biết:Số ID của dự án: PRJ001Số ID của chiến thắng : REQBPhiên bản: 1.0.4_draft_B

Trong một dự án, thường có nhiều file source code, phép tắc cơ phiên bản là: các file cùng tạo nên một khối công dụng được gom phổ biến thành một CI.

Kiểm rà phiên phiên bản (Version Control)

Có những định nghĩa và biện pháp hiểu không giống nhau về version control, sinh sống đây shop chúng tôi chỉ muốn định nghĩa nó ở kỹ càng thông dụng, giáp với bạn dạng thân cụm từ nhất.

Version control là sự kiểm soát các phiên bản (version) khác nhau của một CI (bao gồm việc định danh cùng sự lưu trữ CI đó).

Thế phiên bản là gì? một phiên phiên bản là một thực thể bắt đầu của một CI sau thời điểm đã sang 1 hoặc nhiều lần xem xét và vậy đổi.

Hiện có không ít công chũm trên thị trường hỗ trợ cho việc kiểm soát và điều hành phiên bản, một số công vậy thông dụng là: Visual Source Safe của Microsoft, Clear
Case của Rational, CVS (nguồn mở).

Mỗi phiên phản đang có một số trong những ID đầy đủ, cùng được tăng dần cho từng phiên bạn dạng mới.

Lưu ý rằng phiên bản của một CI khác với phiên bản của các file nguyên tố của CI đó. Trong ví dụ như trên, phiên bạn dạng của CI “Exp
Mod” không giống với phiên bạn dạng của file thành phần “Exp
Mod.h” cùng “Exp
Mod.c”. (Xem hình 3)

Các phiên bạn dạng quan trọng của một CI rất có thể được khắc ghi để nhận thấy một “mốc” đặc biệt trong tiến trình phát triển CI đó, phiên phiên bản mà CI được phê chăm bẵm hay baseline.

Quản lý baseline (Baseline Management)

Cũng như Version Control, baseline có rất nhiều cách hiểu khác nhau, trong phạm vi nội dung bài viết này, shop chúng tôi chọn ý nghĩa sâu sắc tương đối phổ biến. Trong thực tiễn thường gặp mặt các nhiều loại baseline sau:


Chức năng (functional)Kế hoạch (planning)Yêu ước (requirements)Sản phẩm (product)Bản cung cấp (release)Kiểm tra (test)Môi trường vận động (environment)
Chọn những CI cho mỗi loại baseline
Tiến hành “ghim chết” baseline trên thời điểm sau khoản thời gian các thay đổi đã được đồng ý chấp thuận và phê chuẩn.

Thông thường, baseline được thực hiện tại điểm hoàn thành của mỗi quá trình hay tại các “mốc” quan trọng đặc biệt trong dự án. Hình 4 cho thấy rõ hơn những loại và thời khắc baseline.

Đồng thời, trong cai quản baseline, vai trò cùng nhiệm vụ của không ít người tùy chỉnh cấu hình hoặc phê chuẩn baseline cũng nên được định nghĩa.

Kiểm soát đổi khác (Change control)

Khi trở nên tân tiến hoặc gia hạn một sản phẩm phần mềm, việc chuyển đổi yêu ước là thiết yếu tránh khỏi.

Mục đích của change control là để kiểm soát tương đối đầy đủ tất cả những thay đổi tác động đến việc phát triển một sản phẩm. Đôi lúc chỉ một vài yêu thương cầu thay đổi nhỏ tuổi của khách hàng hàng, tất cả các chặng của tiến trình phát triển ứng dụng từ thiết kế, mang lại viết code, cho kiểm tra sản phẩm đều phải biến đổi theo.

Nếu các biến đổi này ko được tìm soát ngặt nghèo sẽ dẫn đến tương đối nhiều sai sót. Xét ví dụ sau: 5 xây dựng viên cùng có tác dụng trong một dự án, tuy nhiên chỉ tất cả 3 được thông tin về việc thay đổi thiết kế. Kết quả là khi tích hợp, khối hệ thống sẽ không vận hành được.

Yêu mong trong kiểm soát biến hóa là các sự thay đổi phải được thông báo đến tất cả những tín đồ hoặc nhóm thao tác có liên quan.

Các bước cơ phiên bản của kiểm soát thay đổi bao gồm:


Nghiên cứu, phân tích
Phê chuẩn chỉnh hoặc không phê chuẩn
Thực hiện vấn đề thay đổi
Kiểm tra vấn đề thay đổi
Xác lập baseline mới

Trong kiểm soát và điều hành thay đổi, ta cũng thường gặp gỡ khái niệm “nhóm kiểm soát và điều hành thay đổi” điện thoại tư vấn tắt là CCB (Change Control Board), nhóm này được thành lập trong từng dự án. CCB thông thường bao gồm:


Người QLC H (Configuration Manager)Trưởng dự án công trình (Project Manager)Trưởng đội (Technical Lead)Trưởng team kiểm soát quality (Test Lead)Kỹ sư unique (Quality Engineer)Và đầy đủ ai bị tác động bởi các thay đổi
Bảo đảm tất cả các biến hóa là được các phần tử liên quan nhận biết và tham gia
Xem xét, phê chuẩn hoặc che quyết các biến hóa trên các baseline
Kiểm tra, xác thực các rứa đổi
Phê chuẩn chỉnh các bản phân phối thành phầm (release) đến khách hàng

Báo cáo tình trạng cấu hình (Configuration Status Accounting)

Công bài toán này bao gồm việc ghi thừa nhận và report tình trạng của những CI cũng giống như yêu cầu rứa đổi, tập vừa lòng số liệu thống kê lại về CI, đặc biệt là các CI đóng góp thêm phần tạo cần sản phẩm. Nó vấn đáp những câu hỏi như: bao gồm bao nhiêu file bị ảnh hưởng khi sữa trị một lỗi ứng dụng nào đó?

Kết trái của quá trình này được ghi thừa nhận trong một báo cáo mang tên Configuration Status Accounting Report (CSAR). Report này thường làm rõ những điểm sau:


Liệt kê toàn bộ baseline với CI thành phần hoặc tất cả liên quan.Làm khá nổi bật các Cl vẫn được cách tân và phát triển hoặc vừa bị chũm đổi
Liệt kê các chuyển đổi còn đang dang dở hay đang hoàn thành, và các baseline bị tác động (bởi sự biến hóa đó)

Việc báo cáo này được gia công thường xuyên với định kỳ, xuyên suốt dự án.

Auditing

(Audit là 1 trong những thuật ngữ khôn xiết thường dùng, cho các ngành nghề khác nhau, tuy vậy trong nghành nghề dịch vụ sofware, chúng tôi không tìm thấy từ giờ đồng hồ Việt tương tự phản ánh đủ ý nghĩa, do vậy xin không thay đổi thuật ngữ gốc, nó có chân thành và ý nghĩa gần cùng với “kiểm tra” và “xem xét”). Gồm 3 loại audit thường được thực hiện.


CSAR Audit: Thường được làm sau những lần một CSAR được sản xuất ra, việc kiểm tra bao gồm:Bảo đảm những baseline mới nhất được liệt kê trong CSARBảo đảm toàn bộ CI tạo cho một baseline được liệt kê
Kiểm tra các CI đã bị đổi khác từ lần baseline trước đó, đối chiếu chúng với những yêu cầu biến đổi để khẳng định rằng sự chuyển đổi trên CI là hòa hợp lý.Physical configuration audit (PCA): nhằm mục đích xác minh xem hầu hết gì khách hàng yêu cầu đạt được hiện thực xuất xắc không. Có 2 việc:Kiểm tra vết để đề đạt tính 2 chiều (traceability) giữa yêu cầu người tiêu dùng và việc hiện thực code trong dự án.Xác định số đông gì sẽ được phân phối cho khách hàng (executable files, source code, tư liệu đi kèm…) có đáp ứng yêu cầu người tiêu dùng hay không.Functional configuration audit (FCA): nhằm mục đích mục đích khẳng định những gì người sử dụng yêu cầu đã có được kiểm tra nghiêm ngặt trên thành phầm tạo ra trước lúc giao cho quý khách hay không. Gồm:Kiểm tra dấu để phản chiếu tính 2d giữa yêu thương cầu khách hàng và bài toán kiểm tra sản phẩm.

Quản lý release (Release management)

Trong thực tế, có nhiếu định nghĩa không giống nhau về có mang “release”. Về cơ bản, chúng ta có thể hiểu: quá trình phát triển một phần mềm thường trải qua không ít lần tích hợp, kết quả của các lần tích hợp là một bạn dạng “build”, trong siêu nhiều bạn dạng “build” đó, một số bạn dạng đáp ứng một vài yêu mong đã định hoặc lập chiến lược trước (theo yêu mong khách hàng), sẽ tiến hành gởi cho quý khách hàng để soát sổ hoặc tiến công giá. Các phiên bản build này được gọi là “release”; công việc tạo ra và phân phối các bạn dạng release được điện thoại tư vấn là công việc “release”. Theo cách hiểu này, sản phẩm ở đầu cuối cũng là một phiên bản release, đôi lúc được gọi là “final release”.

Trong quá trình release, việc quản lý đòi hỏi phải triển khai các công việc sau:


Baseline môi trường phát triển thành phầm và các file, tài liệu (sẽ release)Thực hiện báo cáo CSAR (xem khái niệm ở trên)Thực hiện những audit: PCA cùng FCAĐóng gói file với tài liệu sẽ release
Xác nhận đã nhận bản release từ khách hàng

Lưu trữ và chép dự phòng (Backup và archive)

Lưu trữ với chép dự trữ là một hoạt động vui chơi của QLCH và là 1 trong những trong những hoạt động quan trọng phải tất cả của cung cấp phần mềm. Nó giúp khắc phục các trường hợp khủng hoảng rủi ro bị mất mát dữ liệu do thao tác sai, virus, hoặc sự nắm phần cứng/ phần mềm. Ở góc cạnh khác, nó cung cấp cho vận động version control (đã nói sinh sống trên) vào trường đúng theo ta ao ước sử dụng đều version khác nhau.

Lưu trữ cùng chép dự phòng đòi hỏi toàn thể sản phẩm và thành phầm trung gian của dự án phải được định kỳ chép dự trữ trên rất nhiều thiết bị hoặc rất nhiều nơi khác một phương pháp an toàn.

Và khi dự án công trình kết thúc, các vận động sau cần phải thực hiện:


Lưu trữ toàn cục dữ liệu của dự án, tuân thủ quy trình tàng trữ đã được tùy chỉnh (định nghĩa bởi dự án hoặc phương pháp ở cấp công ty).Lưu trữ hoặc huỷ bỏ những tài liệu ở dạng giấy.Dọn sạch tài liệu hoặc thông tin của dự án công trình vừa kết thúc, sau khi đã chép lưu giữ trữ.

Vai trò của các thành viên vào dự án

Trong một dự án điển hình, thông thường có 4 (nhóm) tác dụng sau (thường hotline tắt là role) tham gia triển khai các vận động QLCH:

CM (Configuration manager)


Thiết lập và bảo trì kho tàng trữ (repository) của dự án.Phát triển cùng triển khai những quy trình thủ tục QLCH của dự án.Thiết lập những baseline, ghi nhận chi tiết các đổi khác trên những baseline
Bảo đảm những baseline ko bị đổi khác khi chưa được phê chuẩn.Tổ chức cùng điều phối những cuộc họp của CCB
Giám gần kề các vận động QLCH.Bảo đảm các yêu cầu cần thiết cho chuyển động QLCH. Ví dụ: khoảng thời gian thành viên dự án công trình bỏ ra mang đến QLCH, công cụ cung ứng cho QLCH…

CCB (Configuration Control Board)

Bao gồm các thành viên trong dự án, cùng có tính năng như đang nói sinh sống trên.

Các member của dự án

Các thành viên của dự án, bao gồm cả CM, PM với thành viên CCB, gồm trách nhiệm:


Tuân thủ toàn bộ các quy trình giấy tờ thủ tục của phiên bản kế hoạch QLCH (CMP)Tham gia vào team CCB khi bao gồm yêu cầu

Các công cụ làm chủ cấu hình -

Các công cụ thống trị cấu hình -

những công cụ làm chủ cấu hình - những công cụ thống trị cấu hình - những công cụ làm chủ cấu hình -
*

Follow us :
*
*
*
*



*

Các công cụ quản lý cấu hình

Cấu hình vật dụng mạng dạng hình truyền thống

Các lắp thêm mạng thường xuyên được cấu hình bởi 1 quản trị viên sử dụng giao tiếp dòng lệnh CLI. CLI ngay từ ngày đầu có thiết kế cho giao tiếp giữa vật dụng và con người. Mặc dù nhiên, để phục vụ nhu cầu tự động hóa – network automation, bây giờ điều này đã thay đổi.

Khi cần thông số kỹ thuật quan trọng trên một số lớn những thiết bị thì nó sẽ là 1 trong những vấn đề khá lớn trong môi trường thiên nhiên mạng rộng hoặc với những thông số kỹ thuật phức tạp.

*

Để quản lí trị những node trong khối hệ thống mạng, quản lí trị viên thường thực hiện giao thức SNMP để bớt sát các thông số của thiết bị, từ đó tìm ra các sự rứa và giải quyết vấn đề hiện gồm trong hệ thống mạng. SNMP thường xuyên không được thực hiện để thông số kỹ thuật thiết bị bởi vì vấn đề bảo mật và sự trở ngại trong câu hỏi triển khai.

Bây giờ những thiết bị sẽ tiến hành tích hợp sẵn các APIs. Bạn có thể triển khai auto hoá vào việc thực thi và cai quản tài nguyên hệ thống mạng. Thay bởi vì cấu hình thủ công bằng tay các cổng port, access lists, Qo
S, cơ chế cân bằng tải thì bạn cũng có thể sử dụng những công cụ cai quản cấu trong khi Ansible, Puppet giỏi Chef.

Xem thêm:

*

Thay vì thông số kỹ thuật từng thiết bị bạn cũng có thể sử dụng các giao thức và technology như REST, Ansible, Puppet, Chef, python, JSON, XML .v.v. đó là một phương pháp quản lý cấu hình mới được không ít người hưởng trọn ứng. Xu chũm này cũng được xem là làn gió mới tương tự như thách thức mới cho người quản trị mạng.

*

Lợi ích của việc tự động hóa hoá:

Quản lý phiên phiên bản phần mềm của những thiết bị
Quản lý thuộc tính của đồ vật như tên, IP, bảo mật
Cấu hình những giao thức
Cấu hình Access Control List

Một số công cụ cai quản cấu trong khi :

Ansible
Chef
Puppet
Salt
Stack

*

So sánh các công cụ quản lý cấu hình:

Ansible, Chef, Puppet, cùng Salt
Stack hồ hết được phát triển trên căn cơ API để thông số kỹ thuật RESTful API request. Tất cả các vật dụng đều cung cấp JSON với YAML cũng như các định dạng dữ liệu khác