Upload
techwellpresentations
View
700
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Robust configuration management (CM) practices are essential for creating continuous builds to support agile’s integration and testing demands, and for rapidly packaging, releasing, and deploying applications into production. Classic CM—identifying system components, controlling changes, reporting the system’s configuration, and auditing—won’t do the trick anymore. Bob Aiello presents an in-depth tour of a more robust and powerful approach to CM consisting of six key functions: source code management, build engineering, environment management, change management and control, release management, and deployment. Bob describes current and emerging CM trends—support for agile development, cloud computing, and mobile apps development—and reviews the industry standards and frameworks essential in CM today. Take back an integrated approach to establish proper IT governance and compliance using the latest CM practices while offering development teams the most effective CM practices available today.
Citation preview
MM Half‐day Tutorial 6/3/2013 1:00 PM
"Configuration Management Best Practices"
Presented by:
Bob Aiello CM Best Practices Consulting
Brought to you by:
340 Corporate Way, Suite 300, Orange Park, FL 32073 888‐268‐8770 ∙ 904‐278‐0524 ∙ [email protected] ∙ www.sqe.com
Bob Aiello CM Best Practices Consulting
Editor-in-chief of CM Crossroads and author of Configuration Management Best Practices: Practical Methods that Work in the Real World, Bob Aiello is a consultant and software engineer specializing in software process improvement, including software configuration and release management. He has more than twenty-five years of experience as a technical manager at top New York City financial services firms, where he held company-wide responsibility for configuration management. Bob served as vice chair of the IEEE 828 Standards Working Group on CM Planning and a member of the IEEE Software and Systems Engineering Standards Committee (S2ESC) Management Board. Contact Bob at [email protected], via LinkedIn, or visit cmbestpractices.com.
Configuration Management Best Practices
Bob Aiello, Principal Consultant and Author of Configuration Management Best Practices : Practical Methods that Work in the Real World
htt // li k di /i /B bAi ll
1
http://www.linkedin.com/in/BobAiellohttp://cmbestpractices.com
CM Best Practices Consulting © 2013
Who am I?
• CM Lead & Consultant for over 25 years• Editor in Chief at CM Crossroads• Editor-in-Chief at CM Crossroads• Author of CM Best Practices• IEEE Management Board • Tools and process agnostic
The guy called in the middle of the night• The guy called in the middle of the night when the release doesn’t work!
2 April 9, 2013 http://cmbestpractices.com © 2013
Goals of this Course
• Implement Effective Source Code Management practices including variantsManagement practices including variants• Automate build, package and deploy• Establish effective IT Controls• Use industry standards and frameworks• Create a CM function that grows &• Create a CM function that grows & improves
3 April 9, 2013 http://cmbestpractices.com © 2013
More Goals of this Course
• Use CM to support development• Understand the classic four CM functions• Understand the classic four CM functions• Introduce the core CM framework• Examine current and emerging trends• Guidance on implementing Agile CM
Establish IT governance and compliance• Establish IT governance and compliance• Establish your own plan for CM!
4 April 9, 2013 http://cmbestpractices.com © 2013
Goals of Code Management
• Never lose code• Know exactly what is running in Prod• Make a two line fix without any chance of the code regressing (due to the wrong version)
5
What exactly is CM?http://cmbestpractices.com © 2013 April 9, 2013
Configuration Management• Configuration Identification
St t A ti• Status Accounting• Change Control• Configuration Audit
Tracking and Controlling Changes to
6
Tracking and Controlling Changes to Configuration Items
http://cmbestpractices.com © 2013 April 9, 2013
Configuration Identification• Provides a specific and unique identity to each configuration item (e.g. binary, config file, documentation)
• Selecting the configuration items for a t d di th i f ti l
7
system and recording their functional and physical characteristics (Sevocab)
http://cmbestpractices.com © 2013 April 9, 2013
Status Accounting
• Tracking the status of a configuration• Tracking the status of a configuration item throughout its lifecycle.
• Recording and reporting of information needed to manage a
8
information needed to manage a configuration effectively (Sevocab)
http://cmbestpractices.com © 2013 April 9, 2013
Change Control• Establishing checkpoints including
t k i ( P d ti QA UAT)gatekeeping (e.g. Production, QA, UAT) and configuration control.
• Identifying, documenting, approving or rejecting and controlling changes to
9
rejecting, and controlling changes to the project baselines (Sevocab)
http://cmbestpractices.com © 2013 April 9, 2013
Configuration Audit• Inspect and identify the exact version
f fi ti it ( h i l &of any configuration item (physical & functional)
• Independent examination of the configuration status to compare with
10
configuration status to compare with the physical configuration (Sevocab)
http://cmbestpractices.com © 2013 April 9, 2013
CM is a full lifecycle effort• The four functions should be part of a d l t lif l ( ISO/IEEEdevelopment lifecycle (e.g. ISO/IEEE 12207, 15288) • There needs to be an implicit requirement for testing CM itself
11
Leads us to V & V
http://cmbestpractices.com © 2013 April 9, 2013
Verification and Validation• Does the CI meet specified requirements?
• Have the requirements for a specific intended use or application been f lfill d?
12
fulfilled?
http://cmbestpractices.com © 2013 April 9, 2013
Functional description of CM• Easier to understand in the context of a lifecyclea lifecycle • Consisting of six core CM functions• Closely matches the job descriptions of the people doing the work• Can be tailored to your needs
13
Can be tailored to your needs
So what are the six functions?http://cmbestpractices.com © 2013 April 9, 2013
CM Functions• Source Code Management• Build Engineering• Build Engineering• Environment Configuration• Change Control• Release Engineering• Deployment
14
• Deployment
Let's start with a brief overviewhttp://cmbestpractices.com © 2013 April 9, 2013
Source Code Management• Control of every configuration item (e g source code config binaries(e.g. source code, config, binaries, compile and runtime dependencies). • Much more than just checkin and checkout (version control)• Provides sanity to the development
15
y pprocess (reduces cognitive complexity)
http://cmbestpractices.com © 2013 April 9, 2013
Terminology
• Configuration items (CIs) includeConfiguration items (CIs) include binaries, source code, config files and even documents• ISO 1007 notes end user function• Bob says, “anything where getting the
16
y , y g g gwrong version would be bad”
http://cmbestpractices.com © 2013 April 9, 2013
What is Control?
• In CM, control is managing theIn CM, control is managing the evolution of a CI throughout its lifecycle• Change Control• Configuration Control
17
Is control really the right word?
http://cmbestpractices.com © 2013 April 9, 2013
Principles• Code is locked down and can never be lostbe lost• Code is baselined marking specific milestones• Managing variants using branches• Code changed on a branch can be
18
• Code changed on a branch can be merged
http://cmbestpractices.com © 2013 April 9, 2013
More Principles• Processes are repeatable Agile and LeanLean• Traceability and tracking of all changes• Improves productivity and quality
19http://cmbestpractices.com © 2013 April 9, 2013
Best Practices• How do we establish source code management that adheres to thesemanagement that adheres to these principles?• Better question is how does CM add value and help facilitate the development effort?
20
development effort?
http://cmbestpractices.com © 2013 April 9, 2013
Sandboxes• Provide a degree of isolation• Support multiple sandboxes• Support multiple sandboxes• Allows the “what-if” scenario• Cheap and disposible• Make sure that you refresh before commiting your code
21
commiting your code
http://cmbestpractices.com © 2013 April 9, 2013
Variants in the code• Supporting multiple operating systems
22http://cmbestpractices.com © 2013 April 9, 2013
CopyBranches• Example of a copybranch (versus delta)delta)
23http://cmbestpractices.com © 2013 April 9, 2013
Handling a bugfix• We need to change Revision 2, but 3 is already being developedis already being developed
24http://cmbestpractices.com © 2013 April 9, 2013
Inner Merge• You need to merge the change on the bugfix branch back to the main trunkbugfix branch back to the main trunk
25http://cmbestpractices.com © 2013 April 9, 2013
Outer merge• You also might want some new code merged from trunk to the bugfixmerged from trunk to the bugfix
26http://cmbestpractices.com © 2013 April 9, 2013
Software Patterns• Fixing bugs while developing next version of a product in parallelversion of a product in parallel • Support for developers working in parallel• Track component baselinesSoftware Configuration Management
27
Software Configuration Management Patterns By Steve Berczuk
http://cmbestpractices.com © 2013 April 9, 2013
Streams• Provides a clear usage paradigm• Model components and architecture• Model components and architecture• Control flow of changesets• Snapshots create baseline of code• Ability to load a particular snapshot• Strong security authorization and
28
• Strong security authorization and entitlements• Complete history and traceability
http://cmbestpractices.com © 2013 April 9, 2013
Examples• Organize code into components• Use Streams & branches• Use Streams & branches• Make merging viable and traceable• Navigate your repository metadata• Use Tasks to track your work
29http://cmbestpractices.com © 2013 April 9, 2013
Defect & Task Tracking • Track changesets to workitem • Traceability to who made the change• Traceability to who made the change• Makes release notes a breeze to create• Ties back to requirements and test cases
30
cases• Allows for ALM and workflow automation
http://cmbestpractices.com © 2013 April 9, 2013
Globally Distributed team• Managing work for a globally distributed teamdistributed team• Effective communication• Better coordination• Traceability • Visibility
31
• Visibility
http://cmbestpractices.com © 2013 April 9, 2013
Defining the Usage Model• You need to create a clear and compelling usage modelcompelling usage model• Otherwise everyone will do whatever worked well on the last project• Helps even when you have to live with an inferior tool
32
an inferior tool
http://cmbestpractices.com © 2013 April 9, 2013
Training• Training is the “hill to die on”• Best when given by your CM support• Best when given by your CM support team• Includes the process you want them to use• Much more than just vendor training
33
• Much more than just vendor training• Test first and then teach
http://cmbestpractices.com © 2013 April 9, 2013
Future • More robust Application Lifecycle Management solutionsManagement solutions• Integration with the entire ALM• Open standards (OSLC)• Toolchains for everyone!
34http://cmbestpractices.com © 2013 April 9, 2013
Source Code Management• Makes everything else easier to managemanage• Helps to juggle multiple code lines• Improves productivity & quality• Leads us to build engineering!
35http://cmbestpractices.com © 2013 April 9, 2013
Build Engineering• Reliable and repeatable automated process to compile link and packageprocess to compile, link and package code components. • Must handle complex compile dependencies • Continuous integration (or nightly
36
g ( g ybuild)• Visibility into who broke the build
http://cmbestpractices.com © 2013 April 9, 2013
Principles• Builds are understood and repeatable• Builds are fast and reliable• Every configuration item is identifiable• Source and compile dependencies can be easily determined
37http://cmbestpractices.com © 2013 April 9, 2013
More Principles• Code should be built once, but deployed anywheredeployed anywhere• Build anomolies are identified and managed • The cause of broken builds is quickly and easily identified and fixed!
38
and easily identified and fixed!
http://cmbestpractices.com © 2013 April 9, 2013
CI Identity Crisis• Who am I?• What if you cannot reach the version• What if you cannot reach the version control system (VCS)?• CIs should be identifiable outside of the VCS• Breadcrumbs are not enough
39
• Breadcrumbs are not enough• Its tagged so I can build it - right?(not so fast – maybe you can't!)
http://cmbestpractices.com © 2013 April 9, 2013
Version IDs• You need to embed an immutable and unique version IDunique version ID• You must have a procedure to easily pull out the version ID at runtime• Cannot depend upon the version control system (VCS)
40
control system (VCS)• Stamp in the tag or label
http://cmbestpractices.com © 2013 April 9, 2013
How does this help?• Create a sandbox from the tag or label which identifies a baselinelabel which identifies a baseline• Create a variant in the code or bugfix branch• Allows you to create a 2 line fix without any chance of the code
41
without any chance of the code regressing due to a version control issue
http://cmbestpractices.com © 2013 April 9, 2013
Compile Dependencies• Get environment variables understood• You must be able to build at the• You must be able to build at the command line• Developers forget what they set in the IDE• What was that classpath?
42
• What was that classpath?• What libraries did I use?
http://cmbestpractices.com © 2013 April 9, 2013
Independent Build• Code must be built using a different computer account on seperatecomputer account on seperate computer• First time it always fails !• You have to find whatever they forgot to check into version control
43
to check into version control• Verification and validation of the build• Satisfy regulatory requirements (audit)
http://cmbestpractices.com © 2013 April 9, 2013
Overengineering the Build• Beware of overly complex builds• Don't embed calls to the version• Don t embed calls to the version control tool• Use components that can be run separately• Automate everything
44
• Automate everything• Treat this like any other development effort
http://cmbestpractices.com © 2013 April 9, 2013
Continuous Integration• Framework for structuring the entire build package and deploybuild, package and deploy• Determine build and integration issue early in the process • Should include deployment to a test environment
45
environment
http://cmbestpractices.com © 2013 April 9, 2013
Code Analysis• Source code repository helps code analysis in two different waysanalysis in two different ways• Static Code Analysis by providing a repository• Instrument the code using variants• Security Audits
46
• Security Audits• Uncover code defects• Code coverage
http://cmbestpractices.com © 2013 April 9, 2013
Build Frameworks• Build agents• Preflight builds• Preflight builds• Allows use of the build farm• Moves the build framework upstream• Supports rapid iterative development
47http://cmbestpractices.com © 2013 April 9, 2013
Ergonomics of the Build• “Bob-proof” your build• Implicit verification and validation• Implicit verification and validation• Avoid the possibility of mistakes• Each step should be easy to understand• One step should not break the stream
48
• One step should not break the stream• Use dashboards and reports to communicate status
http://cmbestpractices.com © 2013 April 9, 2013
Partnering with Development• Development will always be a step aheadahead• Set entry criteria and require that you get advanced notice of when they change the architecture• Development should be able to build
49
• Development should be able to build the release on the command line
http://cmbestpractices.com © 2013 April 9, 2013
DevOps• Set of Principles where development and operations partnersand operations partners• Better communication• Knowledge sharing• Moving build and deploy upstream
50http://cmbestpractices.com © 2013 April 9, 2013
Future• Focus on complete deployment frameworkframework• Support rapid iterative development• Virtualization and cloud computing leads us to very fast build, package and deploy
51
deploy• Don't forget the automated testing
http://cmbestpractices.com © 2013 April 9, 2013
Environment Configuration• Managing the environments including creation and controlled configurationcreation and controlled configuration• Procedures to manage compile and runtime dependencies (e.g. database access)• Monitoring runtime environment for
52
gunauthorized changes (e.g. ports open)
http://cmbestpractices.com © 2013 April 9, 2013
Principles• Environment configuration dependencies are identified anddependencies are identified and understood• Environments can be interogated for current status• Code is built once and configured
53
• Code is built once and configured using automated procedures
http://cmbestpractices.com © 2013 April 9, 2013
More Principles• Environment configurations should be changed in a controlled and predictablechanged in a controlled and predictable way• Environment configurations should be documented and understood by all
54http://cmbestpractices.com © 2013 April 9, 2013
Supporting Code Promotion• Promotion of code throughout the application lifecycleapplication lifecycle• Environments must be isolated from each other• QA should never “accidently” access production
55
production
http://cmbestpractices.com © 2013 April 9, 2013
Using Tokens• Your code should read $DB1• Substitute the correct database• Substitute the correct database• Centralize environment variable assignment
56http://cmbestpractices.com © 2013 April 9, 2013
Configuration Control• Should identify and control environment configurationenvironment configuration• Trust but verify • Good example of where a CMDB can help keep surveillance during runtime• Depends upon Change Control
57
• Depends upon Change Control
http://cmbestpractices.com © 2013 April 9, 2013
Future• Cloud computing and virtualization are having a huge impactare having a huge impact• Full size environments created on the fly• Sharing a pool of resources• Can I rent a super computer for a few
58
• Can I rent a super computer for a few days please?
http://cmbestpractices.com © 2013 April 9, 2013
Change Control• Management of changes including gatekeeping and configuration controlgatekeeping and configuration control• Process related changes managed through the SEPG• Change Advisory Board (CAB) to evaluate the downstream impact of a
59
pchange• A priori change control
http://cmbestpractices.com © 2013 April 9, 2013
Principles• Changes should be planned and not just last minute eventsjust last minute events• Changes should be understandable, including their downstream impacts• Authority and approvals for changes should be established and obtained as
60
should be established and obtained as appropriate
http://cmbestpractices.com © 2013 April 9, 2013
More Principles• Procedures for emergency changes should be established to covershould be established to cover emergency incidents• Change control should assess and confirm that all configuration management processes are being
61
management processes are being followed
http://cmbestpractices.com © 2013 April 9, 2013
Types of Change Control• A priori• Gatekeeping• Gatekeeping• Configuration Control• Change Advisory Board• Emergency Change Control• Process Engineering
62
• Process Engineering• Senior Management Oversight
http://cmbestpractices.com © 2013 April 9, 2013
A Priori• May I have permission to make that change?change?• Facilitates an ALM task based approach• Who said you could work on that?• Common for defense contractors
63
• Common for defense contractors• My friends at the FAA
http://cmbestpractices.com © 2013 April 9, 2013
Gatekeeping & Configuration
• Is the release ready to be promoted?Is the release ready to be promoted?• What are the downstream impacts?(Hint – check with the CAB)• What happens if we make this change?
64
g
http://cmbestpractices.com © 2013 April 9, 2013
Minding the Process
• Software Engineering Process GroupSoftware Engineering Process Group• Senior Management • What makes something an emergency?
65http://cmbestpractices.com © 2013 April 9, 2013
The 29 Minute Meeting• Change control meetings can be problematicproblematic• Need to be structured and controlled• Entry and exit criteria• Control the dynamics!
66http://cmbestpractices.com © 2013 April 9, 2013
e‐Change Control• Routine changes• Still requires traceability and• Still requires traceability and transparency• Good way to implement the change advisory board (CAB)
67http://cmbestpractices.com © 2013 April 9, 2013
Drive the Entire CM Process• You can drive the entire CM Process from change controlfrom change control• Review the CM Plan• Ensure that there are procedures in place for code promotion• Don't forget the fallback plan
68
• Don t forget the fallback plan• Identify and manage risk
http://cmbestpractices.com © 2013 April 9, 2013
Retrospective• After action review• Need open and honest evaluation• Need open and honest evaluation• Opportunity to improve the process• Drives the entire release process
69http://cmbestpractices.com © 2013 April 9, 2013
Release Management• Consists of Release Engineering and release coordination (PMO)release coordination (PMO)• Packaging and identification (e.g. manifest) of all components built in the build engineering function• Automation to build, package, stage
70
, p g , gand deploy releases• Don't forget being able to rollback!
http://cmbestpractices.com © 2013 April 9, 2013
Principles• Releases should be readily identifiable with an immutable versionidentifiable with an immutable version ID• Releases should be packaged with all dependencies identified and controlled• Packaging should be automated and
71
• Packaging should be automated and and designed to avoid human error
http://cmbestpractices.com © 2013 April 9, 2013
More Principles• Release management should be fast and reliable to facilitate iterativeand reliable to facilitate iterative development• Must be able to audit the release package• Contents of release trackable (audit)
72
• Contents of release trackable (audit)• Release management source of information on status of all releases
http://cmbestpractices.com © 2013 April 9, 2013
Manifest• Documents contents of release packagepackage• Embedded (immutable) version ID• Requires procedure to retrieve version ID• Created through automated
73
• Created through automated procedure• Verifiable through configuration audit
http://cmbestpractices.com © 2013 April 9, 2013
Release Maps• Complete list of release contents with MAC SHA1 or MD5 hashMAC-SHA1 or MD5 hash • Utility to recreate release map and compare to version shipped with release• Should be able to verify MAC-SHA1
74
• Should be able to verify MAC-SHA1 or MD5 hash
http://cmbestpractices.com © 2013 April 9, 2013
My Three Step Process• Common task is to fix the build & releaserelease• Observe the first time and take notes• Then I drive with my checklist and developer at my side• Third time I have some scripts to
75
• Third time I have some scripts to automate parts and my checklist
http://cmbestpractices.com © 2013 April 9, 2013
Release Coordination• More of a PMO function that works closely with Change Controlclosely with Change Control• Release Calendar is essential • Track requirements completed in release notes• Communicate status of release to all
76
• Communicate status of release to all stakeholders
http://cmbestpractices.com © 2013 April 9, 2013
Staging• Essential practice that ensures the success of the deploymentsuccess of the deployment• Should be fully automated• Must be fully traceable• Configuration audit verifies successful completion
77
completion
http://cmbestpractices.com © 2013 April 9, 2013
Future• Complete release and deployment frameworkframework• Both open source and commercial solutions• Integration with the ALM• Status of my deploy on the dashboard
78
• Status of my deploy on the dashboard
http://cmbestpractices.com © 2013 April 9, 2013
Deployment• Should be the smallest of the functionsfunctions • Should be engineered to be a push button lightswitch• Requires full traceability • Run by Ops
79
Run by Ops• Rollback is essential• Relies upon release engineering
http://cmbestpractices.com © 2013 April 9, 2013
Principles• Promoting a release should be as simple as possiblesimple as possible• Backing out a release should be as important as promoting• Promoting a release should be fully traceable with an audit log of all
80
traceable with an audit log of all changes
http://cmbestpractices.com © 2013 April 9, 2013
More Principles• Only Ops should be involved with deploymentdeployment• Separation of controls essential for compliance• Unauthorized changes should be detected
81
detected• Configuration audit to verify• Retrospective & ongoing improvement
http://cmbestpractices.com © 2013 April 9, 2013
I Make Mistakes• But I will always be able to tell you what mistakes I madewhat mistakes I made• Full traceability• Few steps, if any, are done manually• Verification that steps were completed correctly is essential
82
correctly is essential• Automate everything!
http://cmbestpractices.com © 2013 April 9, 2013
Communicating the Deploy• Communication to all stakeholders is essentialessential• Announce outages and completed deployments• Should be automated and part of a console
83
console
http://cmbestpractices.com © 2013 April 9, 2013
Smoke Testing• Last step of the deploy is always testingtesting• CM should be part of the QA and testing function
84http://cmbestpractices.com © 2013 April 9, 2013
Current and Emerging Trends• Agile principles are impacting CM in many essential waysmany essential ways • We will talk about Agile CM next• Agile ALM – related to status accounting• Tracking the status of a configuration item is essentially the lifecycle
85
item is essentially the lifecycle• Agile release planning• Focus on process maturityhttp://cmbestpractices.com © 2013 April 9, 2013
Changing Landscape
• Cloud computing and virtualizationCloud computing and virtualization• OSGi – plug and play• Application servers to handhelds• Can we get that build & deploy done now?
86
• Continuous Integration becomes Continuous CM
http://cmbestpractices.com © 2013 April 9, 2013
Paradigm Shift• In many organizations deployment means giving up your weekendgiving up your weekend• We need to shift the way that we look at deployment • Making the deploy a non-event• You don't believe so I will quote a few
87
• You don t believe so I will quote a few colleagues
http://cmbestpractices.com © 2013 April 9, 2013
Let's Talk About Agile
A il hift th fAgile shifts the focus...
(But you will also see that there will be much in common)
88http://cmbestpractices.com © 2013 April 9, 2013
Goals of Agile CM
R idl b ild k d d l• Rapidly build, package and deploy• Reliable and repeatable process• Traceability and forensics
89http://cmbestpractices.com © 2013 April 9, 2013
CM for AgileCM that is adapted to suit the continuous nature of change that Agile providesnature of change that Agile provides without sacrificing the values of CM.
Adapting Configuration Management for Agile Teams: Balancing Sustainability and Speed by
90
ea s a a c g Susta ab ty a d Speed byMario Moreira
http://cmbestpractices.com © 2013 April 9, 2013
Agile on CM
B t ll d t A ilBut we really need to use Agile principles to implement Agile CM
91http://cmbestpractices.com © 2013 April 9, 2013
Agile Configuration Management
Individuals and interactions over processes and toolsp
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
92http://cmbestpractices.com © 2013 April 9, 2013
Characteristics of Agile CM• Customer centric (which one?)
R id it ti d l t• Rapid iterative development• Pragmatic approach to requirements• Support for testing• Collaborative communication • Role in the SCRUM
93
• Role in the SCRUM
April 9, 2013 http://cmbestpractices.com © 2013
More to Agile CM than just CI• Continuous Delivery
Li ht i ht (l )• Lightweight (lean ceremony)• Easy to maintain (respond to change)• Continuous Integration (of course!)• Devops focus on the full ALM
94
What are the first seven things?
http://cmbestpractices.com © 2013 April 9, 2013
Agile Release Train (ART)Making each product a successful and routine event – an event that is indeed planned and eagerly anticipated yet one one that happens almost on autopilot
Dean Leffingwell’s Agile Software Requirements, p. 299
95http://cmbestpractices.com © 2013 April 9, 2013
Build in the Cloud• Virtualization allows you to create a f ll d b ild bfully resourced build box• Make the build fast with no penalty for frequent builds• Builds should be logged and traceable• Make sure you can tag “interesting”
96
• Make sure you can tag interesting builds and purge unneeded builds
http://cmbestpractices.com © 2013 April 9, 2013
Architect Your Build for CM• Architect Your Application to facilitate CM ( i t bl i ID )CM (e.g. immutable version IDs)• CM also helps facilitate an effective architecture• Overly complex builds are a huge waste
97
waste• Rapidly changing architecture can outpace the build
http://cmbestpractices.com © 2013 April 9, 2013
Lessons From ITIL• Configuration Management Database (CMDB)(CMDB)• Federated CMDB• Configuration Management System• Definitive Media Library (DML)
98
Devops = Agile + ITIL
http://cmbestpractices.com © 2013 April 9, 2013
Puppet/Chef• Automate provisioning, patching and
fi ti f ti t dconfiguration of operating system and application components• Systems integration framework• Scalable and extensible• Used in other deployment frameworks
99
• Used in other deployment frameworkswww.puppetlabs.com www.opscode.com
http://cmbestpractices.com © 2013 April 9, 2013
Continuous Deployment• Rapid iterative deployment• Automate everythingAutomate everything• Keep the deployments small• Minimize risk• Easier to deal with problems • Ability to fall back is importantAbility to fall back is important
100http://cmbestpractices.com © 2013 April 9, 2013
Common Problems• Deployments can be risky• Missing a single step can result inMissing a single step can result in problems• Too many mistakes• Takes too long • No way backNo way back• Assumed defeat
101http://cmbestpractices.com © 2013 April 9, 2013
Deployment PipelineA deployment pipeline is … an
t t d i l t ti fautomated implementation of your application’s build, deploy, test and release process
Jez Humble and David Farley’s
102
Jez Humble and David Farley s Continuous Delivery, p 3.
http://cmbestpractices.com © 2013 April 9, 2013
Aim of the Pipeline• Makes building, deploying, testing and releasing software visible to everyone involved
I f db k th t bl• Improves feedback so that problems are identified, and so resolved, as early in the process as possible• Enables teams to deploy and release any version of their software to any environment at ywill through a fully automated process (p. 4)
103http://cmbestpractices.com © 2013 April 9, 2013
Antipatterns• Deploying Software Manually
D l i t P d ti lik• Deploying to Production-like environment only after Development is complete• Manual Configuration of Production Environments
104
EnvironmentsContinuous Deployment, p. 7 – 10
http://cmbestpractices.com © 2013 April 9, 2013
Verification & Validation
• Deming – build quality in g q y• Test your own framework• Configuration Audit• Consider the ergonomics of your automation
http://cmbestpractices.com © 2013 105 April 9, 2013
Ergonomics of Build & Release• Cockpit of a plane
C t l t d• Controls are easy to read• Traceability• Designed to avoid mistakes
106http://cmbestpractices.com © 2013 April 9, 2013
Devops
• Synergy of Agile & ITILy gy g• Full lifecycle approach • Good communication to all stakeholders• Break down barriers• Don’t forget separation of rolesDon t forget separation of roles
http://cmbestpractices.com © 2013 107 April 9, 2013
Dev/QA Focus• Development
QA & T ti• QA & Testing• Operations• Self Managing/Organizing Teams
108http://cmbestpractices.com © 2013 April 9, 2013
Agile Focus On Seven Items1. Source Code Management2 B ild d R l E i i2. Build and Release Engineering3. Environment Configuration4. Continuous Integration5. Continuous Deployment6 Verification and Validation
109
6. Verification and Validation7. Devops
http://cmbestpractices.com © 2013 April 9, 2013
Skills for CM guru• Hands-on technical • At least some development skills• At least some development skills• Strong scripting (e.g. Perl, Python, Ruby)• Knowledge of some frameworks or standards
110
standards• Process orientation (enjoy improving the process)
http://cmbestpractices.com © 2013 April 9, 2013
CM/Devops• Flexible technical background• Good knowledge of development• Good knowledge of development• Knowledge of QA/Ops• Strong automation skills• Some systems administration• Ability to work across silos
111
• Ability to work across silos
http://cmbestpractices.com © 2013 April 9, 2013
Toolsmith/Devops• Strong technical background• Strong scripting skills• Strong scripting skills• Diving deep into the tools including troubleshooting• Understands toolchains and finds flexible solutions
112
flexible solutions• Process orientation – focus on traceability
http://cmbestpractices.com © 2013 April 9, 2013
IT Governance & Compliance• IT Governance needs to be in alignment with corporate governancealignment with corporate governance• Financial reports needs to be accurate• Separation of controls• Security measures to prevent
113
• Security measures to prevent unauthorized access• Audit in place for intrusion detection
http://cmbestpractices.com © 2013 April 9, 2013
Sox Compliance• Section 404 of the Sarbanes Oxley Act of 2002Act of 2002• Using ISACA Cobit 4.1 • 34 high level IT controls• PCI compliance• SAS-70
114
SAS 70
http://cmbestpractices.com © 2013 April 9, 2013
ISO 9001• Establishes the quality management systemsystem• ISO 90003 is the software standard in the 9000 family of standards • Uses ISO 12207 (or 15288) to specify lifecycle processes
115
lifecycle processes• ISO 10007 for CM• IEEE 828, EIA 649-A, Mil Std coming!
http://cmbestpractices.com © 2013 April 9, 2013
Which Standards?• IEEE 828 – CM Planning• EIA 649 A Non compliance• EIA 649-A – Non compliance• ISO 90003 to support QMS• Full lifecycle ISO 12207
Tailor !
116
Tailor !
http://cmbestpractices.com © 2013 April 9, 2013
Moving Upstream• Dev to CM to QA to Ops
C f ti l f• Cross functional focus• Speed up development• Build a great deployment architecture• Give it to Devs as a service!
117http://cmbestpractices.com © 2013 April 9, 2013
Frameworks• ITIL v3 including CMDBs, federated CMDBs CMS DMLCMDBs, CMS, DML…• Cobit for SOX• CMMI ->>>> Agile
118http://cmbestpractices.com © 2013 April 9, 2013
The CM Process• Should be Lean• Processes need to be reviewed• Processes need to be reviewed• Tailor down or tailor up• More collaboration and consensus building• Use standards and frameworks
119
• Use standards and frameworks
April 9, 2013 http://cmbestpractices.com © 2013
Assessment• First step is to assess current practices “As Is”practices - As-Is• Compare to industry standards and frameworks• Determine “To-Be” • Create a plan for improving your CM
120
• Create a plan for improving your CM processes
April 9, 2013 http://cmbestpractices.com © 2013
Plan for Improvement• Improve training and use case for source code managementsource code management• Improvement build automation• Setup or improve continuous integration• Automate package and deployment
121
• Automate package and deployment• Create procedures for configuration audit
April 9, 2013 http://cmbestpractices.com © 2013
Configuration Management• Configuration Identification
St t A ti• Status Accounting• Change Control• Configuration Audit
Tracking and Controlling Changes to
122
Tracking and Controlling Changes to Configuration Items
http://cmbestpractices.com © 2013 April 9, 2013
Goals of this Course
• Implement Effective Source Code Management practices including variantsManagement practices including variants• Automate build, package and deploy• Establish effective IT Controls• Use industry standards and frameworks• Create a CM function that grows &• Create a CM function that grows & improves
123 April 9, 2013 http://cmbestpractices.com © 2013
More Goals of this Course
• Use CM to support development• Understand the classic four CM functions• Understand the classic four CM functions• Introduce the core CM framework• Examine Current and emerging trends• Implement Agile CM – the first 7 things
Establish IT governance and compliance• Establish IT governance and compliance• Establish your own plan for CM!
124http://cmbestpractices.com © 2013 April 9, 2013
Configuration Management Best Practices
Bob Aiello, Principal Consultant and Author of Configuration Management Best Practices : Practical Methods that Work in the Real World
htt // li k di /i /B bAi ll
125
http://www.linkedin.com/in/BobAiellohttp://cmbestpractices.com
CM Best Practices Consulting © 2013