Sự khác biệt giữa DevOps và Quản lý cấu hình phần mềm

Sự khác biệt giữa Hoạt động phát triển và Quản lý cấu hình phần mềm là gì?

Đối với tôi dường như giống như miễn là cả DevOps và Quản lý cấu hình phần mềm đều tập trung vào:

1. Thiết lập cơ sở hạ tầng phát triển - chịu trách nhiệm kiểm soát phiên bản , quản lý xây dựng, quản lý triển khai, quản lý phụ thuộc, tích hợp và phân phối liên tục , v.v.
2. Sử dụng thực tiễn tốt nhất để tổ chức môi trường phát triển .
3. Đảm bảo chất lượng của các quy trình phát triển - thu thập các số liệu về hiệu quả phát triển, làm việc để loại bỏ các tắc nghẽn của quy trình phát triển (chạy thử nghiệm đơn vị, đánh giá phạm vi kiểm tra đơn vị, kiểm tra chạy, v.v.)
4. Quản lý cơ sở hạ tầng - nền tảng mục tiêu và chi tiết cụ thể của nó.
5. Quản lý phát hành - đảm bảo phát hành đã được gửi đến khách hàng / khách hàng kịp thời.

Có lẽ tôi đang thiếu một cái gì đó? Liên kết này cho thấy việc sử dụng thuật ngữ 'Quản lý cấu hình phần mềm' chiếm ưu thế. Tuy nhiên, kết hợp từ nào bạn muốn sử dụng để mô tả phạm vi hoạt động được liệt kê: Hoạt động phát triển hoặc Quản lý cấu hình phần mềm ?

Các thuật ngữ mô tả các khái niệm và trách nhiệm rất giống nhau, và nói chung chúng có phần đồng nghĩa. Thuật ngữ "DevOps" là một từ tương đối mới, được phổ biến bởi hội nghị Devopsday Ghent 2009 và các sự kiện Devopsday tiếp theo . Nó được mô tả tốt nhất trong sơ đồ này :

Mặt khác, Quản lý cấu hình phần mềm là một thuật ngữ được thiết lập nhiều hơn trong nghề nghiệp và xuất phát từ thuật ngữ Quản lý cấu hình không dành riêng cho phần mềm . Quản lý cấu hình phần mềm thường được tham chiếu trong ngữ cảnh kỹ thuật phần mềm, một định nghĩa đơn giản được đưa ra bởi Roger Pressman trong "Kỹ thuật phần mềm: Cách tiếp cận của một học viên" :

là một tập hợp các hoạt động được thiết kế để kiểm soát thay đổi bằng cách xác định các sản phẩm công việc có khả năng thay đổi, thiết lập mối quan hệ giữa chúng, xác định các cơ chế quản lý các phiên bản khác nhau của các sản phẩm công việc này, kiểm soát các thay đổi được áp dụng và kiểm tra và báo cáo về các thay đổi đã thực hiện.

Mặc dù tất cả các thuật ngữ bạn tham chiếu đều mơ hồ, DevOps dường như chỉ là một cách ít chính thức hơn để mô tả ít nhiều cùng một bộ nguyên tắc như Quản lý cấu hình hoặc Quản lý cấu hình phần mềm nếu nhìn từ quan điểm của nhà phát triển phần mềm, đặc biệt là ưu tiên các nhóm kết hợp chặt chẽ :

DevOps là một phản ứng đối với nhận thức ngày càng tăng rằng có một sự mất kết nối giữa những gì được coi là hoạt động phát triển theo truyền thống và những gì được coi là hoạt động truyền thống. Sự ngắt kết nối này thường biểu hiện là xung đột và kém hiệu quả.

Trong cùng một bài viết, những điểm tương đồng với SCM được ghi chú:

Thêm vào Bức tường nhầm lẫn là tất cả sự không phù hợp quá phổ biến trong công cụ phát triển và vận hành. Hãy xem các công cụ phổ biến mà các nhà phát triển yêu cầu và sử dụng hàng ngày. Sau đó hãy xem các công cụ phổ biến mà quản trị viên hệ thống yêu cầu và sử dụng hàng ngày. Với một vài ngoại lệ đáng chú ý, như trình theo dõi lỗi và có thể SCM , chắc chắn bạn sẽ thấy nhiều hứng thú khi sử dụng các công cụ khác hoặc tích hợp đáng kể giữa chúng. Ngay cả khi có một số chồng chéo trong các loại công cụ, thường thì việc triển khai sẽ khác nhau trong mỗi nhóm.

Đối với việc sử dụng các thuật ngữ, so sánh của bạn không thực sự có ý nghĩa:

1. SCM là tập con của CM, không phải là một thuật ngữ cạnh tranh,
2. DevOps là một thuật ngữ khá mới, không có điểm nào so sánh với các điều khoản đã được thiết lập,
3. DevOps xuất phát từ Hoạt động của nhà phát triển (rõ ràng) nhưng hiếm khi được mở rộng như vậy.

Cá nhân tôi là người quản lý cấu hình phần mềm Sr trong nhiều năm (10+) Tôi nghe các thuật ngữ không khớp trong nhiều tình huống thực tế. Nó không phải là hiếm đối với nhân viên kỹ thuật không do tính chất tương đối của các vị trí. Cả hai đều có vai trò, nhu cầu và yêu cầu cụ thể tương tự nhau nhưng theo tôi có thể phân chia rõ ràng.

Tôi tin rằng cách tốt nhất để mô tả sự phân chia các vai trò này là tập trung vào tính tương đối của chúng với sự tương tác. Có nghĩa là, Quản lý cấu hình phần mềm tập trung vào các hệ thống và môi trường bên trong, cùng với việc tích hợp, triển khai, phát hành và quản lý mã nguồn. Khi các hoạt động của nhà phát triển (DevOps) tập trung nhiều hơn vào khía cạnh hoạt động của kiến ​​trúc ứng dụng bên ngoài, trong khi vẫn duy trì sự hiểu biết rõ ràng về mã khi nó được sử dụng và thực hành môi trường của nó. Nếu hiệu suất của máy đang có dấu hiệu xuống cấp, giao tiếp giữa nhiều ứng dụng bị lỗi, giao tiếp giữa doanh nghiệp với doanh nghiệp (BtB) và / hoặc kiến ​​trúc liên quan đến môi trường sản xuất, thì bạn sẽ tìm đến Chẩn đoán của Nhà phát triển để chẩn đoán và giải pháp.

Thông thường, theo kinh nghiệm của tôi, Trình quản lý cấu hình phần mềm cũng có thể thực hiện những việc này, nhưng điều này sẽ lấy đi trọng tâm cốt lõi của chúng là theo dõi, quản lý và triển khai các cấu hình môi trường và sửa đổi phần mềm. Quản lý phần mềm cho phép phân tách nhiệm vụ, theo dõi lỗi và lỗi, theo dõi dự án và vòng đời phát triển phần mềm và dòng chảy. Các tác vụ này không phải là trọng tâm cốt lõi của Hoạt động dành cho nhà phát triển và do đó ít bắt buộc hơn, nhưng vẫn có thể được thực hiện.

Tôi đã thấy nhiều trường hợp nhầm lẫn của mỗi, và trong mỗi trường hợp có một số chéo chéo hạn chế. Tuy nhiên, điều quan trọng nhất là nghĩ về sự khác biệt giữa trách nhiệm của từng vị trí độc lập liên quan đến trọng tâm chính của họ. Chủ yếu khi làm việc với các hệ thống và phần cứng được sử dụng nội bộ để quản lý cấu hình môi trường và phát hành sản phẩm, bạn sẽ tìm kiếm Trình quản lý cấu hình phần mềm. Mặt khác, khi xử lý hiệu suất hệ thống, giám sát, nghiên cứu và chẩn đoán các hệ thống được sử dụng bởi khách hàng của bạn, bạn nên tìm đến Hoạt động của nhà phát triển hoặc DevOps.

Bây giờ, đây không phải là một câu nói hay, cũng không phải là một câu trả lời dứt khoát, mà là một nhận dạng cá nhân về sự khác biệt của từng vị trí. Tôi muốn biết nếu tôi đang ở ngoài cơ sở, hoặc nếu mọi thứ được làm rõ hơn bằng câu trả lời này.

Bạn sẽ khó lòng tìm ra một định nghĩa vững chắc cho DevOps. Đó là một ý tưởng nhiều hơn là một công việc phải làm. Và đó là một ý tưởng quá mới để mọi người đồng ý về chính xác ý nghĩa của nó. Tuy nhiên, đây là của tôi.

DevOps thực sự chỉ là một thuật ngữ mới để quản lý cấu hình, nhưng nó được chọn để chỉ ra rằng vai trò không phải là vai trò một người, đó là sự hợp tác giữa nhóm phát triển và nhóm vận hành.

Trong lịch sử, việc quản lý cấu hình sẽ chỉ được thực hiện bởi nhóm phát triển và sau đó chuyển giao cho các hoạt động, những người sẽ xem tất cả với sự nghi ngờ sâu sắc. Đó là đủ công bằng, phải trung thực. Họ chịu trách nhiệm về nó. Họ là những người đầu tiên được gọi vào lúc 4 giờ sáng khi nó gặp trục trặc. Họ thực sự nên có một số tham gia vào sự phát triển của nó.

Đây là cách làm rõ đơn giản cho câu hỏi: DevOps là một thuật ngữ được sử dụng để mô tả sự phối hợp hoặc mối quan hệ giữa Phát triển (phát triển mã chương trình trong môi trường phát triển) và Hoạt động (đảm bảo thời gian tối đa của môi trường sản xuất).

Quản lý cấu hình phần mềm là một phương tiện để đạt được sự phối hợp này. SCM liên quan đến các công cụ và kỹ thuật để quản lý tự động hóa quá trình chuyển từ phát triển sang sản xuất (hoạt động)

Để tóm tắt, SCM kết nối Dev và Ops.

Tôi thấy DEVOP đang ở cuối thực thi hoạt động - kịch bản tự động hóa triển khai, xây dựng môi trường, đại loại thế. SCM, mặt khác, là về tính toàn vẹn của sản phẩm và quản lý hiệu quả và truy xuất nguồn gốc của các thay đổi đối với các sản phẩm. Tôi luôn xem ALM là một phần của SCM - sau tất cả, làm thế nào bạn có thể quản lý các thay đổi đối với sản phẩm của aa nếu bạn không biết về trình điều khiển cho sự thay đổi hoặc ai đã thực hiện chúng? Các khung triển khai có thể rơi vào một trong hai bên - và bên nào sẽ luôn phụ thuộc vào nhu cầu pháp lý của tổ chức bạn làm việc - sau tất cả - bạn có muốn nhà phát triển có thể thực hiện hack nhanh, điều đó có nghĩa là máy lọc máu của bạn chỉ hoạt động đúng 99,99% đôi khi, hoặc bạn cần tình huống đó để cho phép bạn hack mã trang web của mình vì nhà phát triển của bạn có địa chỉ IP được mã hóa cứng?