configuration management (cm) source code control配置管理（cm）的源代码控制

Configuration Management (CM)*,Source code controlVersioningBuild Management,*Some of this material adapted from Ian Sommervilles course notes, Ch. 29, and Wigerd, L. and Seiwald, 1998,Change Management,Change happens!Dont get frustrated as to “why”, but understand that it will happen for a variety of reasons:Sales uncovers a “cant miss opportunity” if they just had one more featureCustomers and business analysts provide incomplete and ambiguous requirementsTechnology foundation changesand a zillion other reasonsChange Management processes identify what needs to be changed and who it impactsWe discuss at length in 416, for you what is important is that many source code files may change in response to one change event.,The development & application of procedures & standards to manage an evolving software productNew versions are created as software evolvesFor different machines/OSOffering different functionalityTailored for particular user requirementsCM is concerned with managing evolving softwareSoftware change is a team activityCM aims to control the costs and effort involved in making changes to a systemMay be seen as part of more general quality and change management processes,Configuration management (CM),CM and CM,What happens when multiple changes affect the same artifacts?,CHANGEEVENT,CHANGEEVENT,abc.java,def.java,xyz.java,CONTENT BLOCKED Due to copyright infringement.,CM Concepts:Configurations & Releases,Configuration: An instance of a system composed of specific versions of its artifactsIncludes expectations of the target environment(s)Release: An instance of a system distributed to users outside of the development teamReleases may be targeted for (in)external communities,def.java v1.0,xyz.java v3.0,abc.java v2.1,xyz.java v2.0,xyz.java v1.0,abc.java v2.0,abc.java v1.0,Release 2,Release 1,CM Concepts:Codelines & Branches,Codelines define a trajectory for a collection of (source code) artifactsYou have a historyYou have a notion of where it is goingYou have a set of policies governing participationBranch - A branch is a named variant of a codeline. That is a collection of software artifactsAssigned a logical identifierWhose purpose is to be either folded back into the main codeline, or maintained as a release.,CM Concepts:Workspace & Repository,A source code control (SCC) repository is a shared file system of software artifacts (server-side)Typically supported with client/server toolsTypically understands versions and variant semantics of the artifactsOften provides some mechanism for assigning jobs to change control on software artifacts.Workspaces are local (client) repositoriesWhere developers build, test, & debug.Developers must periodically synch with SCC repository,CM Tools,A configuration management tool is one that manages the acceptable set of configurations targeted for different releasesA source code control tool is a repository that manages the (source code) artifacts associated with a project An SCC repository is part of a larger CM system. CM also includes tools and processes for building deployable (executable) artifacts from the SCC repository.,Branching/Merging (per artifact),From /bradapp/acme/branching/,Exclusive locking one codelineChanges visible immediately after check-in,Concurrent development using branching multiple codelines,Synchronize concurrent development using merges merge between codelinesChanges private and not part of mainline until merge better supports large, long changes,CM Best Practices,Branching: Mainline model (yes) Promotion Model (NO!)Branches: variants of the code artifacts.Branch only when necessary.Dont copy when you mean to branch.Branch on incompatible policy.Branch late.Branch, instead of freeze.,CONTENT BLOCKED Due to copyright infringement.,CM Best Practices*,Codelines:Give each codeline a policy.Give each codeline an owner.Have a mainline.Change propagation: getting changes from one codeline to another.Make original changes in the branch that has evolved the least since branching.Propagate early and often.Get the right person to do the merge.,*Wingerd & Seiwald, 1998. See References,CONTENT BLOCKED Due to copyright infringement.,CM Best Practices*,Workspaces:Dont work outside of managed workspaces Stay in sync with the codeline. Dont share workspaces.Dont use jello views.Check in often.,*Wingerd & Seiwald, 1998. See References,abc.java,def.java,METADATA,Local Repository,abc.java,def.java,SCC Repository,CONTENT BLOCKED Due to copyright infringement.,Sandboxes and Vendor Branches,A couple of problems solved with these concepts:You have an idea not fully fleshed out that you want to prototype as part of a requirements understanding activity. You want to put the code under SCC, but it shouldnt be part of the main product (yet, until the requirements are validated)Solution: Use a “Sandbox”, which is a separate codeline with distinct quality (checkin) policiesYou need to track dependencies to open source (or COTS if you have the code) artifacts and manage changes to this underlying platform.Solution: use a vendor branch, which allows one to re-checkin the new vendor version and resolve merge conflicts,SCM Classes of Information*,Examples:Introduction: What are the CIs (Configurable Items)Mgmt: Can be tricky in secure, multi-vendor, & IP-sensitive envsActivities: The main “stuff” you do to make CM happen (next slide)Schedules: Relationships to master project plan for change procsResources: Tools, repositories, guides, training, etc.Plan Maintenance: Managing change to the CM process,*IEEE Standard 828-2005,SCM Activities,Configuration Identification: Identify, Name, Describe what needs change controlConfiguration Control: Identify need for change, analyze, approve/disapprove, verify/releaseConfiguration Status Accounting: What metrics are to be tracked?Number and frequency of changes on an itemConfiguration Evaluation & Reviews: Essentially a validation task - does the configured software (baseline) meet requirements?Release Mgmt & Delivery: Description of how software is built and released to external users, and plans for managing change post-release. (stay tuned),Recommended Reading,Sommerville, Ian. Software Engineering, 7th ed., Chapter 29. Addison-Wesley, 2004.Wingerd, L. and Seiwald, C. “High-level Best Practices in Software Configuration Management”, ECOOP 98, SCM-8, Springer-Verlag LNCS 1439, 1998.Fogel, K. and Moshe, B. Open Source Development with CVS (3rd ed.) Available at .IEEE Standard 828-2005, IEEE Standard for Software Configuration Management PlansSoftware Engineering Body of Knowledge (SWEBOK), Chapter 7, Software Configuration Management, 2004,1/5/2018,17,The process of compiling and assembling software components into an executable systemProduct lines built from combinations of componentsInvariably supported by automated tools that are driven by build scriptsi.e. Ant, Maven, Make, CMake,System building,abc.java,def.java,perties,xyz.xml,foo.exe,1/5/2018,18,Example Build Issues,Do build scripts include all required components?When there are many hundreds of components making up a system, it is easy to miss one. This is normally detected by a build verification toolIs the appropriate component version specified?A more significant problem. A system built with the wrong version may work initially but fail after deliveryAre all configuration files available?These and 1000+ other things canmake the process go bad,System Build Process,All activities provide status and results to Build Management SystemBuild system executes build scripts against specific course code versionConfiguration identifies artifact versions for buildBuilt tools generate and package deploy artifactsPost-build may include executing tests (JUnit) and deployment,Build Script (Ant-based),SourceArtifacts,GeneratedArtifacts,Packaged fordeployment,Build Management System(results, logs, notification),CM System,Build(compiler, etc.),Post-build(deploy, validate),Test results,1/5/2018,20,System representation,Systems are normally represented for building by using filenames to be processed by build tools. Dependencies between files described to build toolsMistakes can be made as users lose track of which objects are stored in which filesIt is useful to know the distinction between compile-time dependencies and run-time dependencies,abc.java,foo.exe,JDBC,Mysql.jar,Common Build Goals,Ensure all required components are includedChanges over time as system growIdentify changes going into this buildTightly coupled with CM and change trackingAbility to recreate the software version builtShare builds with the team includingWhat was built code version, which work itemsLogs, Test results, Build resultsBuild validation tasks depends on type of buildRelease full validation, Complete testing functional, perf/scale, code coverage, etc.Milestone partial validationMost tests no surprises before releaseBuild “smoke test”, a small, reliable subset of testsGoal is quick, yet reliable validation,Release,. . .,Build,1/5/2018,22,Build Management Best Practices,Define the process.Know WHO owns the build & WHO is the customer.Know WHAT the requirements for the build areKnow WHERE the build is targeted to go.Number/ID your builds - use mnemonics that suggest the source code version and platformChange Management - know what changed from build to build - code and build scriptsValidate the result how is it accepted? What tests to run?Track build process defectsMake external dependencies explicit - 3rd party packages, configuration files, etc.If possible, have developers use the build tools,Jakarta Ant,Ant is a Java-based build toolOriginally written by James Duncan Davidson on an airplane from Europe to the US.As a Java developer, he tired of makes poor cross-platform abilitiesLike make for Java only betterUses an XML file to drive actionsBenefits of AntCross-platform, runs anywhere Java runsJava domain smart (Junit, Eclipse)Extremely powerful, modular, extensibleFast, optimized (ex: javac run once for all subdirectories)Extensible, strong community supportJust a few alternatives maven, cernunnos,Ant Example build.xml file, ,Target to execute if none specified,All activity relative to basedir. Uses build.xml files directory if omitted,Properties are ants user-defined variables,Targets group a collection of commands to execute,Properties,Ants parameterize-abilityUsing properties$ to use a property value in build fileSetting propertiesName/value Load properties from properties fileLoad environment variablesUseful Ant built-in properties: set to s name attribute basedir set to build files directory unless changed in ,Ant Targets,Targets contain order tasks to execute when target is invokedTargets can depend on other targets that must execute before their executionAll targets have these attributesname (required)Common names init, compile, cleandepends (comma separated list of other targets to execute first)description (for projecthelp)if/unless (conditional execution).unless,Useful Target Examples,initSet up properties, single definition for entire build fileCan be set directly or in a property file ,Useful Target Examples,prepareCreate directories needed for building/packagingCopy files to locations for packaging/deploying cleanRemoves all generated artifacts from build process ,Useful Target Examples,compileCompiles code in source directories to destination directoryPowerful classpath and classpath referencingPerforms .java/.class out-of-date checking ,Useful Target Examples,distCreate any directory structures needed for building/packagingCopy files to locations for packaging/deploying ,Ants Types,Ant has several tags that function like data typesPatternSet, FileSet, DirSet, Path-Like StructuresUsed by tasks to select groups of filesAll have an id attribute so they can be specified and referenced lat