Kiểm soát phiên bản sơ đồ và mã nguồn

Tôi đang phát triển một thiết bị điện tử có hai phần: phần cứng (sơ đồ Eagle) và phần sụn (mã nguồn C ++). Tôi muốn theo dõi các thay đổi trong cả mã nguồn và sơ đồ, nhưng có một số điểm tôi không chắc chắn về cách tổ chức công việc của mình:

• Đối với mã nguồn tôi chắc chắn sẽ sử dụng Git. Nhưng các sơ đồ có giá trị phiên bản khi chúng thực sự là các tệp nhị phân (các phiên bản Eagle mới sử dụng một số định dạng XML, nhưng nó không dễ đọc như vậy ...)?

• Có phải là ý tưởng tốt để đặt các nguồn và sơ đồ vào một kho lưu trữ Git? Nó sẽ có ý nghĩa, nhưng mặt khác nhật ký của tôi sẽ chứa cả thay đổi phần mềm và phần cứng. Ngoài ra phần mềm có thể có một số chi nhánh, nhưng phần cứng có thể không ...

• Làm thế nào để đối phó với sửa đổi phần cứng? Tag chúng hoặc lưu chúng trong các thư mục riêng biệt?

• Ngoài ra có thể có một số phụ thuộc giữa sửa đổi phần cứng và phiên bản phần sụn. Làm thế nào để đối phó với họ?

Bạn có thể vui lòng chia sẻ thực hành tốt nhất của bạn với tôi?

Hầu hết trong số đó đến với sở thích cá nhân.

Tôi theo dõi mọi thứ tôi làm cho một dự án trong Git. Đặc biệt là vì Git xử lý hầu hết các loại tệp, thậm chí là nhị phân, đủ hiệu quả. (Thay cho Altium SVN tích hợp vô nghĩa)

Một trong những lý do chính của tôi là vì khách hàng của tôi không cảm thấy Dropbox đủ an toàn và tôi cần một hệ thống sao lưu mà tôi có thể truy cập trên toàn thế giới, với một số bối cảnh phiên bản trên hầu hết những gì tôi làm. Vì vậy, tôi đã thiết lập một máy chủ Git riêng và hệ thống sao lưu được mã hóa và nó hoạt động. Bảng, Sơ đồ, Mã, Tài liệu, Báo cáo, Sửa đổi thủ công, mọi thứ đều được theo dõi.

Tôi thường sẽ tạo một Kho lưu trữ cho Phần cứng, một cho Phần mềm và một cho Phần sụn nếu đó là một dự án lớn, có khả năng hoạt động lâu dài, nhưng đối với các dự án dịch vụ nhỏ, ví dụ hoặc thử nghiệm nhỏ tôi thường đặt tất cả vào một kho lưu trữ, vì kết quả sự hỗn loạn sẽ không lớn.

Trong Git, bạn cũng có thể sử dụng các kho lưu trữ phụ để tích hợp Firmware vào dự án Phần cứng hoặc theo cách khác, ngay cả khi chúng là các kho được quản lý riêng.

Đối với các dự án lớn hơn, tôi cũng thường sử dụng các hệ thống theo dõi lỗi để theo dõi các vấn đề và giải quyết, một lần nữa cho CTNH cũng như SW, Mantis là một hệ thống tốt có thể được sử dụng miễn phí.

Đối với các phiên bản phần cứng tôi tạo ra Gerbers hoặc bất cứ thứ gì có bạn, được gắn thẻ Git Hash cho phiên bản đó, những Gerbers đó là những thứ được phiên bản "lỗi thời" riêng biệt trong các thư mục của R01, 02, v.v. Vì bạn không muốn luôn luôn tạo lại chúng, nhưng chúng là các tệp kết quả nên không nên được phiên bản trong chính Git (vì phần mềm thiết kế của bạn phải có tính quyết định với việc tạo nội dung sản xuất, hoặc nếu không ...).

Nếu có điều gì đó thú vị trong R01 không xảy ra trong R02 (hoặc ngược lại), bạn có hai Git Hashing mà bạn có thể so sánh các tệp nguồn, không phải lo lắng.

Như một lưu ý cuối cùng, một ví dụ khái niệm về một dự án, sẽ có một kho lưu trữ Phần cứng, cũng lưu trữ tệp "BoardPinout.h". Tệp này được bao gồm dưới dạng tệp được phiên bản từ xa vào kho lưu trữ Phần sụn, có một vài tệp định nghĩa giao diện được đưa vào từ xa vào kho Phần mềm.

Có nghĩa là mỗi khi tôi thay đổi một vài tín hiệu mà không sửa đổi chức năng rộng, dự án CTNH "cập nhật" BoardPinout, sau đó có thể được cập nhật và sử dụng trong Firmware, v.v.

1) Nó chắc chắn có giá trị phiên bản sơ đồ / bảng tập tin. Ngay cả khi bạn không thể theo dõi sự khác biệt một cách dễ dàng, bạn vẫn có một cách rõ ràng để trở lại một bản phát hành phần cứng cụ thể nếu bạn phải làm việc với bản sửa đổi thiết bị cũ.

2) Chúng tôi có cấu trúc sau trong SVN của chúng tôi.
/ tag
/ chi nhánh
/ trung kế / phần cứng
/ trung kế / phần mềm / phần sụn

Nếu có thể áp dụng với nhiều thư mục con hơn như có thể / Firmware và / ConfigTool cho phần mềm và / mainboard và / bo mạch chủ hoặc một cái gì đó tương tự cho phần cứng.

2) Thẻ được tạo từ các thư mục con không phải từ toàn bộ thân cây, như Tag / Mainboard-v1.2.345. Phần cứng (cụ thể là PCB) luôn chứa bản sửa đổi SVN trong bản in lụa hoặc bằng đồng để có một tài liệu tham khảo trực tiếp.

4) Sự phụ thuộc giữa phần cứng và phần sụn có thể phức tạp. IMO nó không có ý nghĩa nhiều để xử lý nó ở cấp độ kho lưu trữ ngoại trừ để lại nhận xét hữu ích về các cam kết.
Xem xét mã hóa thay đổi phần cứng bằng cách sử dụng chân I / O dự phòng. Một cái gì đó như sử dụng 4 chân để mã hóa 16 phiên bản phần cứng khác nhau. Chúng tôi cũng đã sử dụng một đầu vào ADC với các giá trị điện trở khác nhau để mã hóa các phiên bản. Bằng cách này, phần mềm có thể "biết" phần cứng nào nó chạy và thay đổi / vô hiệu hóa / kích hoạt các tính năng cụ thể.