Ai chịu trách nhiệm thiết lập hệ thống xây dựng tự động?

Tôi là một người quản lý dự án tại công ty của tôi. Tôi làm việc với một vài nhóm các nhà phát triển bằng cách sử dụng một hệ thống kiểm soát phiên bản tiêu chuẩn, nổi tiếng được gọi là CVS. Tôi muốn thấy tích hợp liên tục và các bản dựng tự động được triển khai để giúp ngăn chặn sự cố với việc phá vỡ bản dựng và với các triển khai xấu lén lút vào các máy chủ sản xuất.

Tôi chắc chắn rằng tôi có thể tự thiết lập điều này, nhưng tôi không muốn tự làm điều này vì hai lý do:

1. Tôi không có thời gian cho nó. Tôi có trách nhiệm của riêng mình, liên quan đến tiếp thị, giao tiếp với các bên liên quan khác với các thành viên trong nhóm không phải là một phần của sự phát triển, giao tiếp với khách hàng và lập kế hoạch dự án.

2. Quan trọng nhất, tôi là người quản lý dự án. Mục đích của tôi là cung cấp sự lãnh đạo, không quản lý vi mô cho nhóm phát triển .

Một số điều mà tôi có thể làm để tìm ai đó trong nhóm phát triển, người sẽ đam mê thiết lập điều này là gì? Nhà phát triển có phải là người phù hợp cho nhiệm vụ này không, vì nó đòi hỏi kiến ​​thức về Java, Spring và Google App Engine? Một số lời khuyên để giúp thúc đẩy thay đổi nơi sợ thay đổi là gì?

Trước tiên tôi muốn nghiên cứu một số khả năng. Chẳng hạn, Hudson là một máy chủ tích hợp liên tục khá phổ biến và cực kỳ linh hoạt. Bạn có thể gửi e-mail cho nhóm nhà phát triển của mình bằng một cái gì đó như thế này:

Tôi muốn giới thiệu một công cụ tích hợp liên tục để các bản sửa đổi độc hại xuất hiện sớm hơn nhiều so với sau này. Tôi đã xem [hudson, acme CIS, foo] và tất cả chúng trông giống như chúng sẽ hoạt động. Với thực tế là chúng tôi đang sử dụng CVS với [liệt kê danh sách ở đây], tôi đang tìm kiếm các đề xuất và tôi sẽ sống với bất cứ điều gì nhóm quyết định.

Dave, xin vui lòng chịu trách nhiệm để có được sự đồng thuận và có được điều này và chạy. Nhóm - vui lòng gửi thông tin của bạn đến Dave vào cuối ngày thứ năm để chúng tôi có thể kiểm tra điều này vào thứ Sáu.

Vui lòng gửi cho tôi thông tin đăng nhập của tôi khi chúng tôi có một cái gì đó được thiết lập.

Cách tiếp cận này có những lợi ích sau:

• Bạn đang ủy thác, không bán phá giá
• Mọi người biết bạn đã thực hiện một số nghiên cứu, chất lượng của những thứ bạn chỉ ra giúp xác định kỳ vọng của bạn về chất lượng của công cụ được triển khai
• Bạn biết về [hãy cẩn thận], chúng ta đừng bị trật bánh khi thảo luận về chúng trừ khi chúng thực sự là những kẻ phá vỡ thỏa thuận cho nhiệm vụ trong tay
• Bạn cho phép một chút dân chủ. Chắc chắn, bạn sẽ đăng nhập để xem nếu có bất cứ điều gì bị phá vỡ, nhưng những người phải đối phó với CIS sẽ là những người chọn nền tảng.

Trong kịch bản giả của tôi, Daveđã được chọn vì anh ta có ít nhất trên đĩa của mình và có lẽ sẽ không gặp vấn đề gì khi thiết lập một máy chủ mới. Tùy thuộc vào khối lượng công việc, Davecó thể phải là bạn. Đó là chủ quan mà tôi chỉ đơn giản đề cập đến nó. Bạn không thể luôn luôn nói not my job to do thatđặc biệt nếu bạn là người duy nhất có thời gian để làm điều đó. Nếu tất cả mọi người đã kéo theo thời gian, nhận thức của họ về sự sẵn sàng giúp đỡ của bạn trở nên quan trọng hơn. Đo lường đó là một kỹ năng bạn phát triển theo thời gian.

Trong mọi trường hợp, bạn sẽ có máy chủ CIS vào thứ Sáu hoặc chi tiết về lý do tại sao điều đó là không thể nếu không có thêm một bàn tay.

Tôi thấy nó đi theo ba cách có thể:

1. Có ai đó trong nhóm phát triển đưa ra một đánh giá nhanh về các công cụ có thể và yêu cầu anh ta nhanh chóng lấy thứ gì đó. Nếu các dự án riêng lẻ của bạn có các tập lệnh xây dựng phù hợp (nghĩa là bạn có thể xây dựng các dự án bên ngoài IDE) thì việc nối chúng với CI sẽ khá nhanh chóng.

2. Hãy coi cơ sở hạ tầng xây dựng là một dự án nội bộ trong nhóm của bạn và quản lý nó như vậy. Tham gia nhiều hơn một chút so với điểm đầu tiên nhưng nếu được thực hiện đúng, bạn sẽ có được một hệ thống tốt hơn. Ngoài ra việc truyền bá kiến ​​thức qua nhóm sẽ giảm nguy cơ chuyên môn hóa quá mức được đề cập dưới đây. Bạn cũng đạt được những lợi ích của đánh giá ngang hàng. Tuy nhiên, một số lập trình viên có thể coi nhiệm vụ này là hạ thấp và vì thế họ có thể không chi tiêu nhiều như vậy nếu họ cần.

3. Thuê một dev làm chủ xây dựng và yêu cầu anh ta thiết lập tất cả các công cụ. Sau đó tiếp tục sử dụng anh ta để cải thiện hệ thống, thêm số liệu, tạo tài liệu tự động, kiểm tra tự động, v.v ... Điều này tốn kém hơn nhưng nếu được thực hiện đúng, các khoản đầu tư vào người này sẽ thanh toán rất nhanh bằng cách tăng hiệu quả của nhóm nhà phát triển của bạn. Người này nên thành thạo với các ngôn ngữ và khung được sử dụng bởi nhóm của bạn và có mong muốn dán chúng vào một hệ thống. Mặt khác (từ các bình luận) điều này có thể không nằm trong ngân sách của bạn và việc tạo một vị trí chuyên biệt có thể dẫn đến giải pháp theo tài liệu có thể gây khó khăn cho việc chuyển đổi.

Điều này nói, trước khi bắt đầu bất cứ điều gì hãy chắc chắn những gì bạn thực sự muốn từ nó. Câu hỏi của bạn thiếu một chút chi tiết để hướng bạn đi đúng hướng kỹ thuật. Bạn cần biết những gì bạn muốn đạt được khi sử dụng các công cụ như vậy, bạn cần một tầm nhìn chung về hệ thống mong muốn. Người ta có thể đi một chặng đường dài trong việc tạo ra một môi trường gắn kết tất cả nhưng không có kế hoạch tổng thể để xây dựng, bạn cũng có thể chạy vòng tròn và khiến mọi thứ phức tạp hơn những gì họ đã có.

Một người quản lý tôi đã từng nói rằng các công cụ là tốt nhưng không có quy trình thì chúng vô dụng. Tôi chỉ ước anh ấy sẽ theo dõi mà anh ấy nói khi đến lúc đặt những thứ này vào vị trí ...

Vì vậy, nếu bạn quyết định thuê một ai đó, có những lợi thế nhất định trong việc có được một lập trình viên hơn là một người có nền tảng ITish hơn. Điểm chính là người này có thể dành một chút thời gian và năng lượng để tạo mã keo và các plugin sẽ tích hợp các hệ thống khác nhau lại với nhau trong một hệ thống mạch lạc.

Hy vọng điều này sẽ giúp

Nếu bạn có vai trò lãnh đạo, công việc của bạn là xác định các thành phần / thực tiễn còn thiếu và bạn có trách nhiệm thấy nó được thực hiện chính xác. Nhiệm vụ thực hiện có thể được ủy quyền hoặc không, nhưng cuối cùng đó là trách nhiệm của các nhà lãnh đạo.

Chìa khóa để chấp nhận là sự hiểu biết, hoặc ít nhất là mang lại cho bạn lợi ích của sự nghi ngờ. Bạn có thể nói qua những gì bạn muốn làm và đưa ra các chi phí và lợi ích. Nếu cuộc thảo luận không mang lại hiểu biết, bạn có thể tin tưởng vào sự tin tưởng của họ vào quyết định của mình, nhưng chỉ khi bạn xây dựng loại hình đó.

Nếu đại biểu của bạn làm theo thời gian hạn chế về chuyên môn, hãy đưa nó lên trong một cuộc họp đứng lên hoặc nhóm và yêu cầu một tình nguyện viên. Nếu không có ai đến chỉ đơn giản là giao nó như bạn sẽ làm bất kỳ công việc nào khác.

cập nhật:

Có một cơ cấu tổ chức trong mỗi công ty. Một vai trò lãnh đạo có trách nhiệm đối với các nguồn lực ở cấp đó. Họ cũng có trách nhiệm chỉ ra và giải quyết bất kỳ vấn đề nào. Họ có thể cần thêm tài nguyên và / hoặc đề xuất tại thời điểm bạn đi lên chuỗi. Nếu bạn có thể giải quyết vấn đề, bạn có tùy chọn tự thực hiện một giải pháp hoặc ủy thác. Điều này có thể và nên liên quan đến những người mà nó sẽ ảnh hưởng trực tiếp, lý tưởng nhất là hợp tác với họ.

Tôi không thể nói rằng cấp giám đốc và các vị trí trên không bao giờ chịu trách nhiệm trực tiếp cho một người hoặc nhóm cụ thể trong một công ty. Nó thực sự phụ thuộc vào cấu trúc tổ chức công ty. Tôi đã làm việc tại các công ty mới khởi nghiệp nơi CTO chịu trách nhiệm trực tiếp cho các nhà phát triển và người thử nghiệm. Trong một công ty quản lý công ty lớn hơn truyền thống ở cấp đó sẽ không có khả năng hiển thị hoặc mức độ quen thuộc cần thiết để đưa ra quyết định phù hợp ở các cấp thấp hơn đó.

Tôi chủ yếu là một nhà phát triển và tôi đã thiết lập nó khi tôi có thể (cụ thể là khi tôi không bị cấm làm như vậy). Nói chung, vì nơi tôi làm việc là các cửa hàng .NET, tôi chọn CruiseControl.NET vì đây là nguồn mở, hoạt động với hầu hết các hệ thống kiểm soát nguồn chính và tương đối dễ sử dụng. Tôi đã luôn muốn thiết lập một Ambient Orb là một trong những đầu ra, nhưng điều đó thường nằm ngoài tầm kiểm soát của tôi.

Hãy đưa nó vào một cuộc họp để xem trước tiên nếu có ai muốn làm điều đó - miễn là nó không ảnh hưởng đến các dự án mà họ hiện đang làm.

Tại địa điểm hiện tại của tôi (một trong những phòng thí nghiệm quốc gia), chúng tôi đã thiết lập nó chỉ để tạo ra các bản dựng một cách nhất quán để mọi người muốn xem những gì chúng tôi đang làm có thể có được phiên bản có thể chạy bất cứ lúc nào . Họ không muốn thử nghiệm đơn vị (ấn tượng của người quản lý dự án là nỗ lực chúng tôi bỏ ra cho các thử nghiệm đơn vị có thể đã được đưa vào dự án chuyển sang .NET).

Ở vị trí trước đây của tôi, mục đích là tạo ra các bản dựng tiêu chuẩn và nhất quán trên các sản phẩm. Quá nhiều sản phẩm chỉ có thể được xây dựng trên một máy tính đặc biệt (trong trường hợp một sản phẩm, liên quan đến sự kiểm soát của bên thứ 3 với DRM hung hăng đã ngừng hoạt động từ lâu, chúng tôi phải giữ một máy tồn tại trong khoảng 5 năm sau khi nhà phát triển bỏ việc bởi vì ông là người duy nhất có thể xây dựng sản phẩm vận chuyển thương mại đã được thay thế này). Hơn nữa, việc cài đặt chỉ có thể được thực hiện bởi một người là một người buổi sáng - vì vậy nếu bạn cần một bản dựng sau khoảng 3 giờ chiều, bạn đã đợi cho đến ngày hôm sau.

Nhà phát triển có phải là người phù hợp cho nhiệm vụ này không, vì nó đòi hỏi kiến ​​thức về Java, Spring và Google App Engine?

Nó phụ thuộc. Nếu bạn có một số người QA giỏi viết kịch bản, hãy hỏi trước khi gán họ cho nó.

Thiết lập nó để bắt đầu không phải là một nhiệm vụ phức tạp. Không nên mất hơn một vài ngày để thiết lập (chủ yếu là trong môi trường công ty, những rắc rối đang có một tài khoản để chạy mọi thứ với tất cả các quyền cần thiết) và chạy.

Hãy thử thiết lập nó từ một hướng khác - khi có sự cố trong môi trường sản xuất, hãy đặt trách nhiệm cho nhóm nhà phát triển để khắc phục và khắc phục nhanh. Sau đó giới thiệu ý tưởng về một bản dựng hàng đêm đơn giản biên dịch từ mã mới nhất, tem phiên bản, v.v ... Nếu không xây dựng được, nó sẽ không được quảng bá.

Tôi nghĩ rằng kịch bản xây dựng nên được sở hữu bởi sự phát triển. Khi họ sửa đổi các phụ thuộc hoặc thực hiện các thay đổi, họ là những người tốt nhất để biết cách cập nhật các tập lệnh. Và nói với họ rằng nếu quản lý dự án sở hữu nó, bạn sẽ gọi họ vào một cuộc họp khi có vấn đề.

Bạn chỉ có thể nói trong cuộc họp teem tiếp theo của mình, "OK tôi nghĩ chúng ta nên làm điều này vì. Ai có thể thực hiện nó" Tôi cho bạn tốt hơn thậm chí tỷ lệ cược sẽ có người nói "Chắc chắn tôi sẽ làm điều đó". sau đó bạn không cần phải chiến đấu về nó.