locked
Bit identical builds RRS feed

  • Question

  • I see this was asked a year ago but didn't get a very useful answer so I'll ask again.

    We need to be able to generate bit identical builds from a code base for a medical product.  How can we ensure that at any time in the future we can generate a bit identical EXE from that code base?
    Friday, May 1, 2009 2:37 PM

Answers

  • To accomplish this you must have very tight revision and configuration controls on your entire build environment.  You must capture the exact versions of the libraries used to build the original as well as the exact binary images of the tools used to construct everything (often including OS patch level).  Beware of build time date/timestamps creeping into your binaries via revision control systems and macros.  Even machine names and varying relative/absolute paths can cause issues.  Also, differences in physical disk layouts can impact logical file sizes, so you have to be careful what tools you use to compare files. 

    The only sane way to manage this is to setup dedicated build machines that you carefully manage.  I have worked on projects where we made snapshots of build machine disk partitions (ala Partition Magic or similar tool) and archived those for every product release build.  We disabled automatic patching of the OS and all applications and put the machines behind an extra layer of firewalls to prevent exploits of some ancient OS defects.  And due to the long term nature of some of the projects we also archived matching spare machines and parts.

    The FDA does not require that you get identical results on any random machines.  You simply have to have processes in place that can reproduce any released product.  Once you get the processes in place, it's not very painful and it can be difficult to break.  It's getting there that is painful.  If you are developing medical products with software in them, you should have at least one build meister on your team to manage the process (usually a part-time job after the initial setup and shake-down) and I think you should have at least two dedicated build boxes.  Those boxes should be shinny new about the time you start your project and will have to last a long time.

    Joseph w Donahue joseph@odonahue.com www.odonahue.com
    • Marked as answer by DManA Wednesday, May 6, 2009 2:28 PM
    Wednesday, May 6, 2009 1:08 AM

All replies

  • What are you trying to achieve?  I think a bit more detail may help.


    Pl mark as answer or helpful if you found this useful
    Friday, May 1, 2009 3:43 PM
  • For FDA regulated products you must be able to prove that you can generate bit identical executables from the code base of any released medical product.  In experimenting with building on different build machines using the exact same code generates executables that are not identical.  We need to know why and how to ensure that we are able to do it when audited by the FDA.
    Friday, May 1, 2009 4:04 PM
  • I assume you mean you are setting version compatibility in the project properties to the original executable and it still isn't bit identical?


    Pl mark as answer or helpful if you found this useful
    Friday, May 1, 2009 9:18 PM
  • I don't see such a field in the properties pages.  It's really simple. I build a project and get an exe.  I build the project a bit later and the exe are not identical.  I need to be able to generate identical exes.
    Saturday, May 2, 2009 4:46 PM
  • To accomplish this you must have very tight revision and configuration controls on your entire build environment.  You must capture the exact versions of the libraries used to build the original as well as the exact binary images of the tools used to construct everything (often including OS patch level).  Beware of build time date/timestamps creeping into your binaries via revision control systems and macros.  Even machine names and varying relative/absolute paths can cause issues.  Also, differences in physical disk layouts can impact logical file sizes, so you have to be careful what tools you use to compare files. 

    The only sane way to manage this is to setup dedicated build machines that you carefully manage.  I have worked on projects where we made snapshots of build machine disk partitions (ala Partition Magic or similar tool) and archived those for every product release build.  We disabled automatic patching of the OS and all applications and put the machines behind an extra layer of firewalls to prevent exploits of some ancient OS defects.  And due to the long term nature of some of the projects we also archived matching spare machines and parts.

    The FDA does not require that you get identical results on any random machines.  You simply have to have processes in place that can reproduce any released product.  Once you get the processes in place, it's not very painful and it can be difficult to break.  It's getting there that is painful.  If you are developing medical products with software in them, you should have at least one build meister on your team to manage the process (usually a part-time job after the initial setup and shake-down) and I think you should have at least two dedicated build boxes.  Those boxes should be shinny new about the time you start your project and will have to last a long time.

    Joseph w Donahue joseph@odonahue.com www.odonahue.com
    • Marked as answer by DManA Wednesday, May 6, 2009 2:28 PM
    Wednesday, May 6, 2009 1:08 AM
  • Thank you so much for your informative reply.  It is very helpful.
    Wednesday, May 6, 2009 2:29 PM