Project Build Process Abhijit Bhosale M.Tech (IT) School of Information Technology, IIT Kharagpur
Objective Make utility Version Control systems Bug Tracking Systems Project build process
Configuration Management Configuration Management refers to a set of procedures for managing an evolving software system. It typically includes the following: Version control Support for automated system building Support for automated system testing/bug-tracking Support for multiple platforms Release management http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
Make utility More the files longer it takes for recompilation Using scripts like shell scripts can also help to build big projects, but it will recompile each and every program Make recompiles only changed programs and their dependents
Simple Compilation $ cc file.c http://www.eng.hawaii.edu/tutor/make
Multiple files compilation $ cc green.c blue.c http://www.eng.hawaii.edu/tutor/make
Separate Compilation Compile green.o: cc -c green.c Compile blue.o: cc -c blue.c Link the parts together: cc green.o blue.o http://www.eng.hawaii.edu/tutor/make
Sample makefile target : source file(s) command (must be preceded by a tab) http://www.eng.hawaii.edu/tutor/make
Demo
Macros Macros OBJECTS = data.o main.o io.o project1: $(OBJECTS) cc $(OBJECTS) -o project1 Special Macros $@ The file name of the target. $< The name of the first dependency. $* The part of a filename which matched a suffix rule. $? The names of all the dependencies newer than the target separated by spaces. $^ The names of all the dependencies separated by spaces, but with duplicate names removed. $+ The names of all the dependencies separated by spaces with duplicate names included and in the same order as in the rule.
Advanced Makefiles Special dependencies target :: source1 command1 target :: source2 command2 Custom suffixes and rules.suffixes:.foo.bar.foo.bar: tr '[A-Z][a-z]' '[N-Z][A-M][n-z][a-m]' < $< > $@.c.o: $(CC) $(CFLAGS) -c $<
Version Control System Multiple versions of software Each time you edit a program Versions within a development cycle Test release, Alpha release, Beta release and final release Variations for different platforms Different releases of product with additional features or bug fixes.
Why use version control? Multiple developers working on same code Access to older versions of files Change log Comparison between different versions Multiple versions at same time
Concepts : Repository Repository stores a complete copy of all the files and directories which are under version control Normally, we never access any of the files in the repository directly. Instead, we use commands to get your own copy of the files into a "working directory", and then work on that copy. When we are finished a set of changes, we check (or "commit") them back into the repository Repository and Working directory are totally separate
Concepts: Checkout Copying a module(s) or file(s) from the server to the local directory (working directory) is called a checkout It will create a local copy of files These copies are latest versions of the files available in server
Concepts: check in After checkout and update of a file is done that file is check in back into to the repository This will create a new version of a file in the repository Comments can be added at the check in time to specify reasons of modification Some tools require commit command to be executed after check in
More commands Import/Init Create repository Add Add new file/directory in the repository Update Update the local files with the files from repository Diff Compare different versions of a file Log Obtain the log history of files
Tags Sometimes we need to put together some versions of files together forming a release It s useful for creating branches maintaining track of latest clean builds label some state of the code e.g. bug fixes Important use of tags is to create baselines
Concept: Baseline The IEEE (IEEE Std. No. 610.12-1990) 1990) defines a baseline as: A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. a baseline is a milestone in the development of software that is marked by the delivery of one or more software configuration items and the approval of these SCIs that is obtained through a formal technical review http://www.ecs.csun.edu/~rlingard/pressmanv6ppt/ch27.ppt
Version Control Tools Concurrent Versions System (CVS) is the most widely used in the open software community Microsoft SourceSafe Rational ClearCase WinCVS is an windows client to access CVS repository
Demo
Bug Tracking Bug is also one of the main configuration items Bugs are problems with products where performance is in some way inconsistent with declared performance. (Lohmeyer & Hassel)
Bug Tracking Systems Keep track of bugs Keep track of available/unavailable functionalities for builds and releases Useful for measuring and tracking software quality If integrated with version control systems to provide tighter control over configuration items e.g. integration of Rational ClearCase and ClearQuest
Bug states Created Assigned Open Modified Fixed Verified Closed
Bug tracking Tools Bugzilla Rational ClearQuest GNATS Debian Bug Tracking System SilkRadar Segue Software
Project build process After early phases, in the implementation phase developers develop the code keep checking in the code in the repository When QA phase is stared, all development activities are stopped, an QA branch is created Build manager Check out code on QA branch and make available the test binaries to the QA team for testing
Project build process QA team tests the module Create bug, add appropriate comments like module name, module version (tag), files, bug reproduction steps, severity, priority Assign bug to the user (owner)
Project build process Bug Owner opens a bug checkout the code to be changed on a new bug branch modifies the code to fix the bug check in the modified code on separate branch along with the Bug Id in the check in comments marks the bug as fixed Change Control Board (CCB) Verifies the bug and the changed code Approves the change
Project build process Repository manager merges the code changes from the bug branches of approved bugs on to the QA branch, Build manager builds the code on QA branch QA team tests the code on QA branch verifies the bug fixes approved by CCB Release manager creates a final release by creating a release branch from the QA branch.
Scenario I: Bug Fix First public release of the hot new product 1.0 http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
Scenario I: Bug Fix 1.0 1.3 Internal development continues, progressing to version 1.3 http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
Scenario I: Bug Fix 1.0 1.3 A fatal bug is discovered in the product (1.0), but 1.3 is not stable enough to release. Solution: Create a version based on 1.0 with the bug fix. 1.0 bugfix http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
Scenario I: Bug Fix 1.0 1.3 Note that there are now two lines of development beginning at 1.0. This is branching. 1.0 bugfix http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
Scenario I: Bug Fix 1.0 1.3 The bug fix should also be applied to the main code line so that the next product release has the fix. 1.4 1.0 bugfix http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
Scenario I: Bug Fix Note that two separate lines of development come back together in 1.4. 1.0 1.3 This is merging or updating. 1.4 1.0 bugfix http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
Scenario II: Normal Development 1.5 You are in the middle of a project with three developers named a, b, and c. http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
Scenario II: Normal Development 1.5 1.5a 1.5b 1.5c At the beginning of the day everyone checks out a copy of the code. A check out is a local working copy of a project, outside of the version control system. Logically it is a (special kind of) branch. http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
Scenario II: Normal Development 1.5a 1.5 1.5b 1.5c The local versions isolate the developers from each other s possibly unstable changes. Each builds on 1.5, the most recent stable version. http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
Scenario II: Normal Development 1.5a 1.5 1.5b 1.6 1.5c At 4:00 pm everyone checks in their tested modifications. A check in is a kind of merge where local versions are copied back into the version control system. http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
Scenario II: Normal Development 1.5 1.5a 1.5b 1.5c 1.6 In many organizations check in automatically runs a test suite against the result of the check in. If the tests fail the changes are not accepted. This prevents a sloppy developer from causing all work to stop by, e.g., creating a version of the system that does not compile. http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
Scenario III: Debugging 1.5 1.6 1.7 You develop a software system through several revisions. http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
Scenario III: Debugging 1.5 1.6 1.7 In 1.7 you suddenly discover a bug has crept into the system. When was it introduced? With version control you can check out old versions of the system and see which revision introduced the bug. http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
Scenario IV: Libraries Library A You are building software on top of a third-party library, for which you have source. http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
Scenario IV: Libraries Library A 0.7 You begin implementation of your software, including modifications to the library. http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
Scenario IV: Libraries Library A 0.7 A new version of the library is released. Logically this is a branch: library development has proceeded independently of your own development. Library B http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
Scenario IV: Libraries Library A 0.7 You merge the new library into the main code line, thereby applying your modifications to the new library version. 0.8 Library B http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt
References http://www.sonoma.edu/engineering/courses/ces 592_files/CES592Ninthlecture-Oct26.ppt http://www.ecs.csun.edu/~rlingard/pressmanv6pp t/ch27.ppt http://www.movesinstitute.org/~mcgredo/cvs.ppt http://www.cs.nyu.edu/courses/spring05/v22.0474-001/lec/lec7.ppt http://undergraduate.csse.uwa.edu.au/units/233.41 0/lectures/2004/kennea01/Issue&BugTracking.ppt
Questions