Configuration Management Best Practices

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

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.

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

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

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!

4

April 9, 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)
What exactly is CM?

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

6

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
system and recording th i f
t
d
di their functional
ti
l
and physical characteristics (Sevocab)

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)

8

April 9, 2013

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)

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)

10

April 9, 2013

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

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?

12

April 9, 2013

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?

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

14

April 9, 2013

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)

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”

16

April 9, 2013

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?

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

18

April 9, 2013

More Principles
• Processes are repeatable Agile and
Lean
• Traceability and tracking of all
changes
• Improves productivity and quality


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?


20

April 9, 2013

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


21

April 9, 2013

Variants in the code
• Supporting multiple operating systems


22

April 9, 2013

CopyBranches
• Example of a copybranch (versus
delta)


23

April 9, 2013

Handling a bugfix
• We need to change Revision 2, but 3
is already being developed


24

April 9, 2013

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


25

April 9, 2013

Outer merge
• You also might want some new code
merged from trunk to the bugfix


26

April 9, 2013

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

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

28

April 9, 2013

Examples
• Organize code into components
• Use Streams & branches
• Make merging viable and traceable
• Navigate your repository metadata
• Use Tasks to track your work


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

30

April 9, 2013

Globally Distributed team
• Managing work for a globally
distributed team
• Effective communication
• Better coordination
• Traceability
• Visibility


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


32

April 9, 2013

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

33

April 9, 2013

Future
• More robust Application Lifecycle
Management solutions
• Integration with the entire ALM
• Open standards (OSLC)
• Toolchains for everyone!


34

April 9, 2013

• Makes everything else easier to
manage
• Helps to juggle multiple code lines
• Improves productivity & quality
• Leads us to build engineering!


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

36

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


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!


38

April 9, 2013

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!)

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

40

April 9, 2013

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

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?

42

April 9, 2013

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)

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

44

April 9, 2013

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


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

46

April 9, 2013

Build Frameworks
• Build agents
• Preflight builds
• Allows use of the build farm
• Moves the build framework upstream
• Supports rapid iterative development


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

48

April 9, 2013

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

49

April 9, 2013

DevOps
• Set of Principles where development
and operations partners
• Better communication
• Knowledge sharing
• Moving build and deploy upstream


50

April 9, 2013

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

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)

52

April 9, 2013

Principles
• Environment configuration
dependencies are identified and
understood
• Environments can be interogated for
current status
• Code is built once and configured
using automated procedures

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


54

April 9, 2013

Supporting Code Promotion
• Promotion of code throughout the
application lifecycle
• Environments must be isolated from
each other
• QA should never “accidently” access
production


55

April 9, 2013

Using Tokens
• Your code should read $DB1
• Substitute the correct database
• Centralize environment variable
assignment


56

April 9, 2013

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


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?

58

April 9, 2013

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

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

60

April 9, 2013

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

61

April 9, 2013

Types of Change Control
• A priori
• Gatekeeping
• Configuration Control
• Change Advisory Board
• Emergency Change Control
• Process Engineering
• Senior Management Oversight

62

April 9, 2013

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

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


64

April 9, 2013

Minding the Process
• Software Engineering Process Group
• Senior Management
• What makes something an
emergency?


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!


66

April 9, 2013

e‐Change Control
• Routine changes
• Still requires traceability and
transparency
• Good way to implement the change
advisory board (CAB)


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

68

April 9, 2013

Retrospective
• After action review
• Need open and honest evaluation
• Opportunity to improve the process
• Drives the entire release process


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!

70

April 9, 2013

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

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

72

April 9, 2013

Manifest
• Documents contents of release
package
• Embedded (immutable) version ID
• Requires procedure to retrieve
version ID
• Created through automated
procedure
• Verifiable through configuration audit

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

74

April 9, 2013

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

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

76

April 9, 2013

Staging
• Essential practice that ensures the
success of the deployment
• Should be fully automated
• Must be fully traceable
• Configuration audit verifies successful
completion


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


78

April 9, 2013

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

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

80

April 9, 2013

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

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!

82

April 9, 2013

Communicating the Deploy
• Communication to all stakeholders is
essential
• Announce outages and completed
deployments
• Should be automated and part of a
console


83

April 9, 2013

Smoke Testing
• Last step of the deploy is always
testing
• CM should be part of the QA and
testing function


84

April 9, 2013

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

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

86

April 9, 2013

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

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)


88

April 9, 2013

Goals of Agile CM
• R idl b ild package and d l
Rapidly build,
k
d deploy
• Reliable and repeatable process
• Traceability and forensics


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

90

April 9, 2013

Agile on CM
But
B t we really need t use A il
ll
d to
Agile
principles to implement Agile CM


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


92

April 9, 2013

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


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?

94

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

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

96

April 9, 2013

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

97

April 9, 2013

Lessons From ITIL
• Configuration Management Database
(CMDB)
• Federated CMDB
• Configuration Management System
• Definitive Media Library (DML)
Devops = Agile + ITIL

98

April 9, 2013

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

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


100

April 9, 2013

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

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.

102

April 9, 2013

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)

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

104

April 9, 2013

Verification & Validation
• Deming – build quality in
g
q
y
• Test your own framework
• Consider the ergonomics of your
automation


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


106

April 9, 2013

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


107

April 9, 2013

Dev/QA Focus
• Development
• QA & Testing
T ti
• Operations
• Self Managing/Organizing Teams


108

April 9, 2013

Agile Focus On Seven Items
1.
2.
2
3.
4.
5.
6.
6
7.

Build d Release E i
B ild and R l
Engineering
i
Environment Configuration
Continuous Integration
Continuous Deployment
Verification and Validation
Devops


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)

110

April 9, 2013

CM/Devops
• Flexible technical background
• Good knowledge of development
• Knowledge of QA/Ops
• Strong automation skills
• Some systems administration
• Ability to work across silos


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

112

April 9, 2013

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

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


114

April 9, 2013

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!

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 !


116

April 9, 2013

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!


117

April 9, 2013

Frameworks
• ITIL v3 including CMDBs, federated
CMDBs, CMS, DML…
CMDBs CMS DML
• Cobit for SOX
• CMMI ->>>> Agile


118

April 9, 2013

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


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

120

April 9, 2013

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

121

April 9, 2013

• Configuration Identification
• St t A
Status Accounting
ti
• Change Control
Tracking and Controlling Changes to
Configuration Items

122

April 9, 2013

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

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!

124

April 9, 2013

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

Configuration Management Best Practices

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Configuration Management Best Practices

Similaire à Configuration Management Best Practices (20)

Plus de TechWell

Plus de TechWell (20)

Dernier

Dernier (20)

Configuration Management Best Practices