1 / 12

SCM introduction

SCM introduction. Chu Shu June 2012. SCM overview. Software Configuration Management Vs Source Control Management Target of SCM Everything is traceable – easy to find issue Everything is reproducible – easy to patch the released binaries

aolani
Download Presentation

SCM introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SCM introduction Chu Shu June 2012

  2. SCM overview • Software Configuration Management Vs Source Control Management • Target of SCM • Everything is traceable – easy to find issue • Everything is reproducible – easy to patch the released binaries • Not only for source code, but also for everything related to the release including document, configuration files… -- easy to develop, easy to deploy… • Proper strategy reduce the management work and increate the availability of development environment 2 06/29/12

  3. Continuous Integration & Continuous Delivery • Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. • SCM need to support frequent delivery • SCM need to support automate test • CI reduce the complexity of merge between different branches • Continuous delivery is a set of principles and practices in growing use in software development to improve the process of software delivery. Techniques such as automated testing, continuous integration and automated deployments allow software to be developed to a high standard and easily packaged and deployed to test environments. • SCM need to support automated delivery which means deployment configurations may be stored in SCM 3 06/29/12

  4. SCM – basics • Working on your private branch( workspace ) • Test before delivery • Deliver to main branch( stream ) frequently • Different branch( stream) for different purpose, CI against the main branch • Change Set( activity) is traceable and linked to Work Item ( or CQ artifact…) • Multiple Phase delivery might be used, especially for multi-site environment 4 06/29/12

  5. SCM – merge & branch • Branch – isolate work from others, reduce the impact of the work • Merge – propagate work to others • Merge tool – can auto merge code by syntax analysis, can Not handle binary files, can Not handle merge need semantic analysis • The complexity in merge is technical debt • Balance merge frequency • High frequent merge reduce the complexity of merge • High frequent merge can find issue earlier • High frequent merge reduce the isolation of high risk work 5 06/29/12

  6. SCM methodology – mainline development • SCM methodology introduction – mainline, by release, by feature, by component, by organization… • We use mainline development to support CI • Always CI on mainline • Always deliver new feature to mainline • No other branch which has long lifecycle • Lease “frozen” time on mainline • Reduce merge work between branches 6 06/29/12

  7. SCM methodology – earlier branching Vs late branching • Earlier Branching • Create branch at the beginning of a release • Focus on one release • Development on release stream, CI against release stream • Late Branching • Create branch at the end of a release • Concurrent development on multiple release • Most development on main stream, maintenance on release stream, CI against main stream Release B Release A Release B mainline Release C Release A 7 06/29/12

  8. Non-source code management • 3rd Party software dependency • Stored in SCM – big but easy for rebuild • Not stored in SCM – flexible but may not confuse for rebuild • Store a reference configuration in SCM • In Insight – not store in SCM, reference remote repository during build, store configuration files (supplier file) in SCM, make sure to preserve referenced repository • Document – stored in SCM • Deployment configuration – store in SCM or separate DB 8 06/29/12

  9. SCM Tools – Centralized Vs Distributed • Centralized tools: ClearCase, Jazz SCM, SVN • Usually for commercial development, high manageability • Complexity in administration • Slow, high requirement for network bandwidth • Complex solution for multi-site development • Distributed tools: GitHub, Mecurial • Usually for open source development • Easy to use • Less manageability, need define strategy for CI • Fast, native for distributed development, less requirement for network bandwidth 9 06/29/12

  10. Insight SCM strategy Restricted fix delivery Restricted fix delivery Milestone 1 Milestone 3 Continue feature development Release A( mainline) Continue feature development Continue feature development Milestone 2 Restricted fix delivery M2 DCUT M3 DCUT M1 DCUT M1 released M3 released M2 released 10 06/29/12

  11. www.ibm/software/rational 11 06/29/12

  12. Revision History 12 06/29/12

More Related