1

We do have several Components in our product which are

  1. Component A
  2. Component B
  3. Component C

Dependencies are (if unmet the system fails):

A <-> B
B <-> C

We are currently creating a build pipeline and finally the Software for each component gets packaged into a single firmware image:

A -> Output A
B -> Output B
C -> Output C

Output A + Output B + Output C = Firmware

The firmware gets packed with some documentation and will then be deployed. Deployments should happen every week to testing and every 2-4 weeks to production.

Firmware + Docs = Deployed Software

My problem is now:

  • How do i ensure compatibility between A,B and C given the fact that they are all developed by different teams?

    I saw this question here Looking for best practice for version numbering of dependent software components

    We do have version numbers in place for A,B and C and the overall Firmware has one as well. Are there any best practices or ways to do it?

  • How do i track back compatibility? (Besides looking into the packaged firmware and see which versions got included at a certain point in time)

    I thought about using git tags here and put the Firmware Version number (only shipped products) as a tag on A,B,C.

Community
  • 1
pfried
  • 203
  • 2
  • 7
  • The answer to this depends on how A, B, and C depend on each other. It may also depend on how often you deploy your software. Once a day, once a year, several times per day? However, it seems your first link already answers your first question in depth. – Doc Brown Sep 22 '16 at 05:57
  • I added more information to my question. About the other question: All the answers discuss the meaning of version numbers, but not how a build system can tell if there is an incompatibility. If the only way is version numbers than there need to be increments in version numbers even if there was no change in a part (imagine A + B change, but not C, how to tell if B is still compatible to C) – pfried Sep 22 '16 at 06:06
  • 1
    A build system cannot tell you about incompatibilities, only integration tests can. (Or, you need to run a fully automated integration test suite as part of your build). – Doc Brown Sep 22 '16 at 06:29

1 Answers1

3

How do i ensure compatibility between A,B and C given the fact that they are all developed by different teams?

Your build tools or version control system cannot do this for you. You need integration tests for this, ideally a fully automated integration test suite. How often you run this suite depends on your team, the minimal requirement is once before each deployment, in teams using a CI server this can happen much more frequently, probably several times a day.

We do have version numbers in place for A,B and C and the overall Firmware has one as well. Are there any best practices or ways to do it?

This is fully covered by the link you already mentioned in your question.

How do i track back compatibility? (Besides looking into the packaged firmware...)

Looking into the packaged firmware is not necessarily a bad approach, if you have easy access to the packages, have tools to easily depackage them and archive the packages properly. However, if that does not satisfy your needs, you need to fully automate your packaging process, and make sure the package scripts can grab each version number from every component automatically. Then let the script write those version numbers into a logfile and keep that logfile.

Community
  • 1
Doc Brown
  • 199,015
  • 33
  • 367
  • 565