Managing.NET Software Factory Using SYNERGY/Change Kris Kniaz Kniaz.net

© All rights reserved. Software Factory Process Requirements (1/2) Automation – Builds must be automated – Builds must run often Scale out (Lab to Pilot Plant to Production Facility) – Run the same build process on any environment (Developer Desktop, Integration Server, QA server ) UI and MW code as well as data base code Testable – Support re-runable automated unit tests

Software Factory Process Requirements (2/2) Verifiable – Knowledge of what code (to the file level) was deployed to production in a given release – Trace code change to developer that changed it and change request or defect that precipitated the work. Link binary code to the source code Support concurrent and parallel development – Concurrent: development of the major and minor release at the same time – Parallel: development of many major releases at the same time © All rights reserved.

Code and Product Flow © All rights reserved.

Task and Change Request Flows © All rights reserved.

How this all fits together using Synergy ? QA/Prod © All rights reserved.

How this all fits together using Synergy ? Engineering © All rights reserved.

Synergy Customizations Automated Build Process – NAnt scripts ( – Re-runable NUnit tests ( – Continuous Integration Server – automated process executes build scripts - CruiseControl.NET Synergy Plug-in for CruiseControl.NET (published Sep 2005) Communicates via http request/response with the Synergy servlets – Environment (or locale) specific settings are stored in the configuration files that are dynamically created by the build process © All rights reserved.

CruiseControl.NET integration with Synergy © All rights reserved.

CC.NET synergy plug in configuration ccm.exe syn01 \\syn01\ccmdb63\wwdev %CCM_UID% %CCM_PWD% build_mgr F:\cmsynergy\cruisecontrol F:\cmsynergy\uidb true App1 App1~Int 7601 false Integration false bin build\version.txt root\flash User © All rights reserved.

Auditing Link binary products to source code – Bill of Materials (BOM) concept is built into Synergy – Out of the box utility works only for C files compiled via make, not particularly useful for.NET files, assemblies, NAnt – Solution: During build of each assembly NAnt generates dynamic BOM file NAnt audit target creates “is_product” attribute for assemblies and “bom” attribute for files. Then uses “ccm relate” command to establish a link. Compare deployed code to the released baseline – Synergy does not provide file paths just object names. Therefore Synergy default reports are not useful for comparisons with deployment tools – Solution: Create custom attribute and populate paths from BOM ccm.exe attribute /create projectpath ccm.exe attribute /modify projectpath “file” Passed SOX audit for the build and deployment process © All rights reserved.

Issue: Integrating Synergy and Defect Tracking Software Defect = CR Do not want to create new CR type and flow CR/Defect synchronization would be preferred Planning on using Synergy – Mercury Integration © All rights reserved.

Issue: Managing global code base Architecture of the app must support globalization – Isolate locale (i.e. “en-us” or “fr-ca”) specific logic into configuration files – Store engineering content (exception messages, names of buttons, forms etc…) into resource files that could be managed by a separate SCM process – Establish base code and locale packs Manage development of the base and configuration of “locale packs” in Synergy Use Translation Memory (TM) software to carry out translation. Use CR’s to manage the process – How do you trace changes (change requests, translation defects) to the deployed assemblies? © All rights reserved.

Summary Software Factory Process works! – Improved Software Quality – Automation – Repeatability – Traceability (Audit) – Scalability But.. – High initial development costs – Longer build time – Not easy to adapt to new processes (for example Microsoft BizTalk) – Requires skilled knowledge workers © All rights reserved.