Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
 
 

MM
Half‐day Tutorial 
6/3/2013 1:00 PM 
 
 
 
 
 
 
 

"Configuration Management
Best Practices"
 
 
 

Presented by:...
Bob Aiello
CM Best Practices Consulting
Editor-in-chief of CM Crossroads and author of Configuration Management Best Pract...
Configuration Management Best Practices
Bob Aiello, Principal Consultant and Author of 

Configuration Management Best Pra...
Goals of this Course
• Implement Effective Source Code
Management practices including variants
• Automate build, package a...
Goals of Code Management
• Never lose code
• Know exactly what is running in Prod
• Make a two line fix without any
chance...
Configuration Identification
• Provides a specific and unique
identity to each configuration item (e.g.
binary, config fil...
Change Control
• Establishing checkpoints including
gatekeeping (e.g. Production, QA, UAT)
t k
i (
P d ti
QA
and configura...
CM is a full lifecycle effort
• The four functions should be part of a
development lif
d
l
t lifecycle (
l (e.g. ISO/IEEE
...
Functional description of CM
• Easier to understand in the context of
a lifecycle
• Consisting of six core CM functions
• ...
Source Code Management
• Control of every configuration item
(e.g.
(e g source code config binaries
code, config, binaries...
What is Control?
• In CM, control is managing the
evolution of a CI throughout its lifecycle
• Change Control
• Configurat...
More Principles
• Processes are repeatable Agile and
Lean
• Traceability and tracking of all
changes
• Improves productivi...
Sandboxes
• Provide a degree of isolation
• Support multiple sandboxes
• Allows the “what-if” scenario
• Cheap and disposi...
CopyBranches
• Example of a copybranch (versus
delta)

http://cmbestpractices.com © 2013  

23

April 9, 2013 

Handling a...
Inner Merge
• You need to merge the change on the
bugfix branch back to the main trunk

http://cmbestpractices.com © 2013 ...
Software Patterns
• Fixing bugs while developing next
version of a product in parallel
• Support for developers working in...
Examples
• Organize code into components
• Use Streams & branches
• Make merging viable and traceable
• Navigate your repo...
Globally Distributed team
• Managing work for a globally
distributed team
• Effective communication
• Better coordination
...
Training
• Training is the “hill to die on”
• Best when given by your CM support
team
• Includes the process you want them...
Source Code Management
• Makes everything else easier to
manage
• Helps to juggle multiple code lines
• Improves productiv...
Principles
• Builds are understood and repeatable
• Builds are fast and reliable
• Every configuration item is identifiabl...
CI Identity Crisis
• Who am I?
• What if you cannot reach the version
control system (VCS)?
• CIs should be identifiable o...
How does this help?
• Create a sandbox from the tag or
label which identifies a baseline
• Create a variant in the code or...
Independent Build
• Code must be built using a different
computer account on seperate
computer
• First time it always fail...
Continuous Integration
• Framework for structuring the entire
build,
build package and deploy
• Determine build and integr...
Build Frameworks
• Build agents
• Preflight builds
• Allows use of the build farm
• Moves the build framework upstream
• S...
Partnering with Development
• Development will always be a step
ahead
• Set entry criteria and require that you
get advanc...
Future
• Focus on complete deployment
framework
• Support rapid iterative development
• Virtualization and cloud computing...
Principles
• Environment configuration
dependencies are identified and
understood
• Environments can be interogated for
cu...
Supporting Code Promotion
• Promotion of code throughout the
application lifecycle
• Environments must be isolated from
ea...
Configuration Control
• Should identify and control
environment configuration
• Trust but verify
• Good example of where a...
Change Control
• Management of changes including
gatekeeping and configuration control
• Process related changes managed
t...
More Principles
• Procedures for emergency changes
should be established to cover
emergency incidents
• Change control sho...
A Priori
• May I have permission to make that
change?
• Facilitates an ALM task based
approach
• Who said you could work o...
Minding the Process
• Software Engineering Process Group
• Senior Management
• What makes something an
emergency?

http://...
e‐Change Control
• Routine changes
• Still requires traceability and
transparency
• Good way to implement the change
advis...
Retrospective
• After action review
• Need open and honest evaluation
• Opportunity to improve the process
• Drives the en...
Principles
• Releases should be readily
identifiable with an immutable version
ID
• Releases should be packaged with all
d...
Manifest
• Documents contents of release
package
• Embedded (immutable) version ID
• Requires procedure to retrieve
versio...
My Three Step Process
• Common task is to fix the build &
release
• Observe the first time and take notes
• Then I drive w...
Staging
• Essential practice that ensures the
success of the deployment
• Should be fully automated
• Must be fully tracea...
Deployment
• Should be the smallest of the
functions
• Should be engineered to be a push
button lightswitch
• Requires ful...
More Principles
• Only Ops should be involved with
deployment
• Separation of controls essential for
compliance
• Unauthor...
Communicating the Deploy
• Communication to all stakeholders is
essential
• Announce outages and completed
deployments
• S...
Current and Emerging Trends
• Agile principles are impacting CM in
many essential ways
• We will talk about Agile CM next
...
Paradigm Shift
• In many organizations deployment means
giving up your weekend
• We need to shift the way that we look at
...
Goals of Agile CM
• R idl b ild package and d l
Rapidly build,
k
d deploy
• Reliable and repeatable process
• Traceability...
Agile on CM
But
B t we really need t use A il
ll
d to
Agile
principles to implement Agile CM

http://cmbestpractices.com ©...
Characteristics of Agile CM
• Customer centric (which one?)
• R id it ti d
Rapid iterative development
l
t
• Pragmatic app...
Agile Release Train (ART)
Making each product a successful and
routine event – an event that is indeed
planned and eagerly...
Architect Your Build for CM
• Architect Your Application to facilitate
CM (
(e.g. i
immutable version ID )
t bl
i IDs)
• C...
Puppet/Chef
• Automate provisioning, patching and
configuration of operating system and
fi
ti
f
ti
t
d
application compone...
Common Problems
• Deployments can be risky
• Missing a single step can result in
problems
• Too many mistakes
• Takes too ...
Aim of the Pipeline
• Makes building, deploying, testing and
releasing software visible to everyone involved
•I
Improves f...
Verification & Validation
• Deming – build quality in
g
q
y
• Test your own framework
• Configuration Audit
• Consider the...
Devops
• Synergy of Agile & ITIL
y gy
g
• Full lifecycle approach
• Good communication to all stakeholders
• Break down ba...
Agile Focus On Seven Items
1.
2.
2
3.
4.
5.
6.
6
7.

Source Code Management
Build d Release E i
B ild and R l
Engineering
...
CM/Devops
• Flexible technical background
• Good knowledge of development
• Knowledge of QA/Ops
• Strong automation skills...
IT Governance & Compliance
• IT Governance needs to be in
alignment with corporate governance
• Financial reports needs to...
ISO 9001
• Establishes the quality management
system
• ISO 90003 is the software standard in
the 9000 family of standards
...
Moving Upstream
• Dev to CM to QA to Ops
•C
Cross f
functional f
ti
l focus
• Speed up development
• Build a great deploym...
The CM Process
• Should be Lean
• Processes need to be reviewed
• Tailor down or tailor up
• More collaboration and consen...
Plan for Improvement
• Improve training and use case for
source code management
• Improvement build automation
• Setup or ...
Goals of this Course
• Implement Effective Source Code
Management practices including variants
• Automate build, package a...
Configuration Management 
Best Practices
Bob Aiello, Principal Consultant and Author of 

Configuration Management Best Pr...
Upcoming SlideShare
Loading in …5
×

Configuration Management Best Practices

5,456 views

Published on

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.

Published in: Technology, Business
  • Be the first to comment

Configuration Management Best Practices

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

×