This document discusses best practices for creating a world-class build system. It recommends starting by understanding stakeholders' needs, having a clear vision, and gaining support. The document also advocates for planning builds around product architecture and developer requirements. Additionally, it describes Citrix's build system which dynamically creates environments, builds components, runs tests, and provides reports. The system is optimized for performance, parallelism, and maintaining standards. Overall, the key takeaways are to have a vision, automate as much as possible, and work with others to continuously improve the build system.

1. Creating a World Class Build System Scott EstesRelease Management and OpsCitrix Systems, Inc. May 28, 11

2. AGENDA Getting Started Planning and Design Implementation and Execution Optimizing the System Maintenance and Evolution

4. Know the Stakeholders’ requirements

5. Have a vision

6. Engage, foster and grow support base at all levels

11. Unable to keep pace

16. Performance

17. Parallel development

18. Maintenance

19. Business Continuity

22. Components treated as “black boxes”.

23. Component visions are not tied to releases.

24. Features are released to product when ready.

26. Provide an “Out of the box” Build experience.

27. Support as needed.

29. Creates Build environment.

30. Builds component binaries.

31. Creates installers.

35. Stakeholder(s)

36. Input(s)

37. Control(s)

39. IMPLEMENTATION AND EXECUTION – PRE-BUILD Configure the build environment. At Citrix: A VM creator service dynamically creates virtual build machines using XenServer® technologies. Cb Connect drives to VM Yes VM available? Determine VM type Assign VM to host Start build script No Wait for available VM

40. IMPLEMENTATION AND EXECUTION – BUILD Developer reviews are critical. At Citrix: An add-on to Visual Studio provides an “out of the box” experience while preserving company mandates. Conf. proj/ search Done? Yes No Sign, index symbols, etc. Built? ID what to build Check/ Build deps Compile Yes Get code Create output No Perforce Log error and continue

41. IMPLEMENTATION AND EXECUTION – BUILD At Citrix: Non-Windows Builds are make-based. Done? Yes No Sign, index symbols, etc. Built? Search for makefiles Compile/ Link Yes Get code Create output No Perforce Log error and die

42. IMPLEMENTATION AND EXECUTION – POST-BUILD Create a testable image and supporting build artifacts. At Citrix: A “toolbox” of PowerShell scripts create the DVD and releases the build for testing. Layout config Poll for changes Create reports Get layout info Update Symbol server Release to Test Symbol Server

43. IMPLEMENTATION AND EXECUTION – OUTPUT Test the product and report. At Citrix: A test automation framework executes Build Verification Tests and other test suites. Test config Pass? Execute BVT Execute additional tests Provision test env Yes Report No Skynet Report

45. Performance

46. Parallel development

47. Maintenance

48. Business Continuity

50. Performance

51. Parallel development

52. Maintenance

53. Business Continuity

54. Self-service

56. What binaries changed Test

58. What binaries changed Test

60. Leverage incremental building and architecture.

61. Use dedicated Perforce Proxies.

62. Use as fast hardware as can afford.

63. Isolate Build network.

65. Compile dead code.

66. Ignore dependencies.

67. Ignore the infrastructure.

70. Automate, automate, automate!

71. Test to trust

74. Enable instead of mandate.

75. Talk to others and back it up.