The document outlines a framework for building software in a controlled environment using open source tools like Make and Git, emphasizing the importance of auditing and documenting builds to ensure reproducibility. It discusses the differences between continuous integration and system builds while providing guidance on maintaining build environments and improving software change management processes. The author advocates for a consistent build process that captures version control records and environment details for effective compliance and operational outcomes.

1. Build Audit and Processes A line of sight from DEV to PROD

2. Alec Clews http://alecthegeek.wordpress.com/ http://twitter.com/alecthegeek http://github.com/alecthegeek Voga Consulting http://voga.com.au/ Licensed under Creative Commons Attribution-Share Alike 2.5 Australia License

3. Summary Build software in an audited and managed environment as part of Configuration Management (CM)

4. Using Open Source Tools (Make and Git) as a framework for a controlled build process

5. Agenda The different types of build and the place of the system build

6. Auditing and logging requirements for system build

7. Implementing a CM System Build Framework The Makefile

8. The Driver script

9. The output

10. Motivation This paper takes a “commercial” view on the process of software change management

11. Desire to provide a business value quickly

12. Communicate effectively between team members

13. Reduce the amount of unsatisfying project work rework, report writing,etc...

14. The Change Lifecyle Document and agree the change

15. Implement the change (hack the code and desktop build/testing)

16. Integration build and unit test

17. System Build in a controlled environment

18. System Testing (or UAT, or beta, or ...)

19. Release for distribution or production

20. Continuous Integration vs. System Builds Continuous Integration (c.f. Martin Fowler) Builds rapidly and frequently

21. Runs unit tests

22. Sets up for unit testing framework

23. Happens automagically

24. May only build small pieces

25. May include code instrumentation and additional debugging options

26. System Builds Build for production, or pre-production Compiler optimisation , different configurations etc. Runs on a different schedule

27. Needs documentation

28. May have large scope

29. How might the system build be done? Fetch the sources and build them

30. Ask the developer for already built software!

31. Issues with these approaches. How can we answer such questions as? Which source versions were used

32. Under what configuration was this built? Compiler switches, which libraries and tools (the build configuration ) Can we “re-create the build”?

33. “ re-create the build” is a myth After problems often asked to re-create the environment for forensic testing

34. But if we re-run the build process that does not assure that we will get the same result Version No, dates and time change: trivial difference masks possibly other major changes in our files

35. We usually don't have a record of the previous build configuration and can't re-create it anyway Result: we can't reliably get the same result twice