1. Using UML, Patterns, and Java Object-Oriented Software Engineering Build Management

2. Outline of the Lecture Purpose of Software Configuration Management (SCM) Some Terminology Software Configuration Management Activities Outline of a Software Configuration Management Plan Build Management Continous Integration

3. The Problem The transition from source code to the executable application contains many mechanical steps: Settings required paths and libraries Compiling source code Copying source files (e.g. images, sound files, start scripts) Setting of file permissions (e.g. to executable) Packaging of the application (e.g. zip, tar, dmg) Executing these steps manually is time- consuming and the chance of introducing failures is high

4. Requirements for Build Management Large and distributed software projects need to provide a development infrastructure with an integrated build management that supports: Regular builds from the master directory Automated execution of tests E-mail notification Determination of code metrics Automated publishing of the applications and test results (e.g. to a website) Tools for Build Management: Unix’s Make Ant Maven

5. Activities in Build Management The transition from source code to the executable application contains many mechanical (boring) activities: Settings required paths and libraries Compiling source code Copying source files (e.g. images, sound files, start scripts) Setting of file permissions (e.g. to executable) Packaging of the application (e.g. zip, tar, dmg) Executing these steps manually is time- consuming and the chance of introducing failures is high Automating these steps has its origins in Unix

6. Development of Build Management 1950: Execution of a sequence of commands Job command language scripts 1970s: make Unix tool to support builds with makefiles 1990s: Ant Open source platform independent build tool 2000s: Maven Project management and integrated build tool

7. Example: Build Management in Unix The Unix command make executes compilation of large programs according to a set of dependency rules Dependency rule Tree structure of prerequisites Time stamps of files Example of a dependency rule: main.obj : main.c gcc -c main.c

8. Example Makefile project.exe : main.obj io.obj tlink main.obj, io.obj, project.exe main.obj : main.c gcc -c main.c io.obj : io.c gcc - c io.c

9. Make Make is as powerful as the existing commands it executes However, make has its problems: Complex shell scripts are hard to maintain and hard to debug Different shell commands are needed on different platforms Firs step towards platform independence: Ant

10. Ant, a Platform Independent Build Management Tool Build tool based on Java, http://ant.apache.org Tasks get executed by invoking Java classes, not shell scripts or shell commands Ant allows the execution of tasks such as: compilation execution file system operations (e.g. copy, move) archiving deployment Ant has become a standard in the Java Open Source community Ant build files are platform independent Ant’s build file is an XML document

11. General Structure of Ant Build Files

12. Examples of Ant Tasks Each Ant Task is a Java application. Custom tasks can be implemented in Java to support custom needs.

13. Construction of Ant Build Files The default name for a Ant build file is build.xml The xml root element must be the ‘project’ element The ‘default’ attribute of the project element is required and specifies the default target to use Targets contain zero or more AntTasks The ‘name’ attribute is required AntTasks are the smallest units of the build process

14. % ant Buildfile: build.xml hello: [echo] Hello, World BUILD SUCCESSFUL Total time: 2 seconds Ant Build File Example Execution of build file:

15. Maven Overview A Java project management and integration build tool, http://maven.apache.org/ Maven supports the same functionality as Ant Ant is actually integrated into Maven Maven’s extended functionality Automatically generates a development website containing Project organization information Project development state reports Based on the concept of a central project object model (POM)

16. Maven Capabilities Maven is able to Receive developer artifacts from the programmers’ SCM directory Compile and package the source code Download dependent artifacts from another (external) repository Generate Javadoc websites Generate developer and code metrics Generate websites containing status information to track issues Deploy the compiled source code and the generated website to a webserver

17. Modeling a Project in Maven Project Object Model (POM) Project name, id, description, version number Website URL Issue tracking URL Mailing list URLs SCM directory URL Developer information License information Dependencies Name, version, location of a Java library from jar file Project directory layout Specifies source code and unit test code directories

18. Modeling a Project in Maven (UML) Project Object Model Project Descriptor name currentVersion organization inceptionYear description url Developer Descriptor name id organization roles Repository Descriptor connection developerConnection url Build Descriptor sourceDirectory resources

19. Example: Generating ARENA’s Development Website ARENA uses a SCM master directory at oose.globalse.org ARENA depends on the Java library servlet.jar available in the Ibiblio repository The ARENA website is located on the server sysiphus.in.tum.de Maven compiles the ARENA sources in the programmer’s directory of the developer

20. Modeling a Project in Maven (UML) Project Object Model Project Descriptor name currentVersion organization inceptionYear description url Developer Descriptor name id organization roles Repository Descriptor connection developerConnection url Build Descriptor sourceDirectory resources

21. Project Descriptor for ARENA (in project.xml) arena ARENA 0.9 Bernd Bruegge & Allen H. Dutoit http://wwwbruegge.in.tum.de/ /images/ase_logo.gif 2004 /images/arena.gif ARENA http://sysiphus.informatik.tu-muenchen.de/arena sysiphus.informatik.tu-muenchen.de /www/arena

22. The ARENA Website (Generated by Maven)

23. Team Members and Roles in project.xml Allen Dutoit dutoit Technische Universität München Architect Developer Michael Nagel nagel Technische Universität München Developer Timo Wolf wolft Technische Universität München Developer

24. Generated Website contains a Description of the Team

25. Software Configuration Management Specification in project.xml scm|svn|http|//oose.globalse.org/svn/trunk/examples/arena scm|svn|http|//oose.globalse.org/svn http://oose.globalse.org/svn/trunk/examples/arena/ The repository tag enables Maven to map the user ids used by the SCM tool to the developer names listed in the Maven team site identify developers activities identify source code changes made by the developers

26. Generated Website: Developer Activities (last 30 days)

27. Generated Website: Change Log (last 30 days)

28. Build Management in the project.xml src src **/*.properties **/*.gif The Build tag specifies the programmer’s directory containing the source code to be used for the build

29. Result: Website contains the current source code of ARENA

30. Outline of the Lecture Purpose of Software Configuration Management (SCM) Some Terminology Software Configuration Management Activities Outline of a Software Configuration Management Plan Build Management Continous Integration

31. Typical Problems and Risks in Software Projects Lack of project visibility Nobody knows what is going on Late discovery of faults The later a fault is found, the more expensive it is to fix it. Lack of deployable software “It worked on my machine” Also, horizontal integration testing strategies don’t focus on an early running system. It is often created in the last moment Low quality software Managers and developers make last-minute decisions to deliver a system developed with the above problems.

32. Continuous Integration Motivation Risk #1: The later integration occurs in a project, the bigger is the risk that unexpected faults occur Risk #2: The higher the complexity of the software system, the more difficult it is to integrate its components Continous integration addresses these risks by building as early as possible and frequently Additional Advantages: There is always an executable version of the system Team members have a good overview of the project status

33. Definition Continuous Integration Continuous Integration: A software development method where members of a team integrate their work frequently, usually each person integrates at least daily, leading to multiple integrations per day. Each integration is verified by an automated build including the execution of tests to detect integration errors as quickly as possible.

34. Continuous Integration can regularly answers these Questions Do all the software components work together? How much code is covered by automated tests? Where all tests successful after the latest change? What is my code complexity? Is the team adhering to coding standards? Where there any problems with the last deployment?

35. Modeling a Continuous Integration System Functions: Set up scheduling strategy (poll, event-based) Detect change Execute build script when change has been detected Run unit test cases Generate project status metrics Visualize status of the projects Move successful builds into Software repository Components (Subsystems) Master Directory: Version control (IEEE: Controlled Library). Builder Subsystem: Execute build script when a change has been detected Continuous Integration (CI) Server Management Subsystem: Visualize project status via Webbrowser Notification Subsystem: Publishes results of the build via different channels (E-Mail Client, RSS Feed)

36. Analysis: Functional Model for Continuous Integration Simple Exercise: Develop the functional model!

37. Analysis: Functional Model for Continuous Integration

38. Design: Deployment Diagram of a Continuous Integration System

39. Design of a Continuous Integration System Development Node Manage Programmer’s Directory (IEEE: Dynamic Library) Software Configuration Management client Integrated Development Environment Run build script locally using the Builder Subsystem

40. Design of a Continuous Integration System (Deployment Diagram) Software Configuration Management Node Contains the Master Directory (IEEE: Controlled Library) Runs the Software Configuration Management Server

41. Design of a Continuous Integration System (Deployment Diagram) Integration Build Node Creates & maintains the Software Repository (IEEE: static library) SCM Client interacts with SCM Node if (when) a change has occurred Runs build globally using Builder when a change has been detected Notification component publishes results of the build uses different channels such as E-Mail or RSS Feed

42. Design of a Continuous Integration System (Deployment Diagram) Management Node Visualize build results Visualize project metrics Receive notification about build status

43. Examples of Available Continous Integration Systems Cockpit CruiseControl and CruiseControl.NET Anthill Continuum Hudson List of continuous integration tools: http://confluence.public.thoughtworks.org/display/ CC/CI+Feature+Matrix

44. CruiseControl: Subsystem Overview (not in UML!) Source: http://cruisecontrol.sourceforge.net/overview.html

45. Cruise Control: The Build Loop The daemon process checks for source code changes in the projects If a change has occurred, the subsystem executes the following actions: Obtain all the build artifacts (described in “config.xml”) Possibly via the project.xml file (if Maven is used) Execute the Build file Write the results into a log file (“xml logs”) Send notifications to subscribers.

46. Cruise Control: Reporting Module and Dashboard Reporting: A Java Server Page (JSP) based web page Reads the XML log file Gives access to the build artifacts Shows build & test results Dashboard: An Ajax based web page Gives overview of projects on the cruise control server

47. CruiseControl Directory Layout I Ant binaries Main configuration file Scripts for starting the cruisecontrol server Dashboard configuration file Files needed for operation Log files Projects to be build Build artifacts

48. CruiseControl Directory Layout II Project folders Timestamp named folders for build artifacts Project artifacts of a specific build

49. CruiseControl Webpages http://localhost:8080/cruisecontrol/

50. CruiseControl Webpages http://localhost:8080/dashboard/

51. Getting Started with CruiseControl Download CruiseControl binary distribution http://cruisecontrol.sourceforge.net/download.html Unzip downloaded archive Run cruisecontrol.sh (.bat) Watch the example project being built http://localhost:8080/cruisecontrol Modify config.xml to include your own project

52. Ant References http://ant.apache.org http://codefeed.com/tutorial/ant_intro.html http://blog.ideoplex.com/software/java/ http://www.iseran.com/Java/ant/tutorial/ant_tu torial.html http://www.javaworld.com/javaworld/jw-10- 2000/jw-1020-ant.html

53. Maven References http://maven.apache.org/ http://www.sandcastsoftware.com/articlesandtu torials/index.html http://www- 106.ibm.com/developerworks/java/library/j- maven/ http://www.jpox.org/docs/1_1/tutorials/maven. html

54. Further Reading [Duvall 2007] Paul M. Duvall, Steve Matyas and Andrew Glover: Continuous Integration. Improving Software Quality and Reducing Risk, Addison Wesley, Upper Saddle River, NJ, 2007

55. Tomorrow’s Exercise Goal: Being able to set up and manage continuous integration Team-based organization: The exercise is team-based We recommend a team size of 5 people (4-6) Choose a team leader Equipment: Bring at least 2 laptops per team to the class room Preparations (Mandatory, by midnight) E-Mail the team member names to naughton@in.tum.denaughton@in.tum.de Set up Eclipse on at least one of the team laptops Check out and study the Bumpers project using the information available on the exercise portal : https://wwwbruegge.informatik.tu- muenchen.de/twiki/bin/view/Lehrstuhl/POMSS09Exercises https://wwwbruegge.informatik.tu- muenchen.de/twiki/bin/view/Lehrstuhl/POMSS09Exercises Additional details Will be distributed at the beginning of the exercise session.

56. Deployment in tomorrows exercise

57. Backup Slides

58. Examples of concrete Ant Tasks Each Ant Task is a Java application. Custom tasks can be implemented in Java to support custom needs.

59. Another Ant Example

60. Another Ant Example (2) % ant compile Buildfile: build.xml compile: [mkdir] Created dir: /Users/wolft/Asteroids/classes [javac] Compiling 12 source files to /Users/wolft/Asteroids/classes [copy] Copying 6 files to /Users/wolft/Asteroids/classes/org/globalse/oose/asteroids BUILD SUCCESSFUL Total time: 6 seconds

61. Another Ant Example (3) % ant jar Buildfile: build.xml compile: jar: [jar] Building jar: /Users/wolft/Asteroids/Asteroids.jar BUILD SUCCESSFUL Total time: 2 seconds