Más contenido relacionado La actualidad más candente (20) Similar a Configuration Management Best Practices (20) Configuration Management Best Practices1. 9/9/13
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
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
• 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
1
2. 9/9/13
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
2
3. 9/9/13
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
• Status Accounting
• Change Control
• Configuration Audit
Tracking and Controlling Changes to
Configuration Items
http://cmbestpractices.com
©
2013
6
April
9,
2013
3
4. 9/9/13
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 their functional
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
4
5. 9/9/13
Change
Control
• Establishing checkpoints including
gatekeeping (e.g. Production, QA, UAT)
and configuration control.
• Identifying, documenting, approving or
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 &
functional)
• Independent examination of the
configuration status to compare with
the physical configuration (Sevocab)
http://cmbestpractices.com
©
2013
10
April
9,
2013
5
6. 9/9/13
Ensuring
the
Trusted
Base
• Know what you built
• Deploy the right code
• Verify that it got there
• Detect any unauthorized changes
CM is a full lifecycle endeavor
http://cmbestpractices.com
©
2013
11
April
9,
2013
CM
is
a
full
lifecycle
effort
• The four functions should be part of a
development lifecycle (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
12
April
9,
2013
6
7. 9/9/13
Verification
and
Validation
• Does the CI meet specified
requirements?
• Have the requirements for a specific
intended use or application been
fulfilled?
http://cmbestpractices.com
©
2013
13
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?
http://cmbestpractices.com
©
2013
14
April
9,
2013
7
8. 9/9/13
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
15
April
9,
2013
Source
Code
Management
• Control of every configuration item
(e.g. source code, config, binaries,
compile and runtime dependencies).
• Much more than just checkin and
checkout (version control)
• Provides sanity to the development
process (reduces cognitive complexity)
http://cmbestpractices.com
©
2013
16
April
9,
2013
8
9. 9/9/13
Terminology
• Configuration items (CIs) include
binaries, source code, config files and
even documents
• ISO 1007 notes end user function
• Bob says, “anything where getting the
wrong version would be bad”
http://cmbestpractices.com
©
2013
17
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?
http://cmbestpractices.com
©
2013
18
April
9,
2013
9
10. 9/9/13
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
19
April
9,
2013
More
Principles
• Processes are repeatable Agile and
Lean
• Traceability and tracking of all
changes
• Improves productivity and quality
http://cmbestpractices.com
©
2013
20
April
9,
2013
10
11. 9/9/13
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
21
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
http://cmbestpractices.com
©
2013
22
April
9,
2013
11
12. 9/9/13
Variants
in
the
code
• Supporting multiple operating systems
http://cmbestpractices.com
©
2013
23
April
9,
2013
CopyBranches
• Example of a copybranch (versus
delta)
http://cmbestpractices.com
©
2013
24
April
9,
2013
12
13. 9/9/13
Handling
a
bugfix
• We need to change Revision 2, but 3
is already being developed
http://cmbestpractices.com
©
2013
25
April
9,
2013
Inner
Merge
• You need to merge the change on the
bugfix branch back to the main trunk
http://cmbestpractices.com
©
2013
26
April
9,
2013
13
14. 9/9/13
Outer
merge
• You also might want some new code
merged from trunk to the bugfix
http://cmbestpractices.com
©
2013
27
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
http://cmbestpractices.com
©
2013
28
April
9,
2013
14
15. 9/9/13
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
29
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
http://cmbestpractices.com
©
2013
30
April
9,
2013
15
16. 9/9/13
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
31
April
9,
2013
Globally
Distributed
team
• Managing work for a globally
distributed team
• Effective communication
• Better coordination
• Traceability
• Visibility
http://cmbestpractices.com
©
2013
32
April
9,
2013
16
17. 9/9/13
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
33
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
http://cmbestpractices.com
©
2013
34
April
9,
2013
17
18. 9/9/13
Future
• More robust Application Lifecycle
Management solutions
• Integration with the entire ALM
• Open standards (OSLC)
• Toolchains for everyone!
http://cmbestpractices.com
©
2013
35
April
9,
2013
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
36
April
9,
2013
18
19. 9/9/13
Build
Engineering
• Reliable and repeatable automated
process to compile, link and package
code components.
• Must handle complex compile
dependencies
• Continuous integration (or nightly
build)
• Visibility into who broke the build
http://cmbestpractices.com
©
2013
37
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
http://cmbestpractices.com
©
2013
38
April
9,
2013
19
20. 9/9/13
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
39
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!)
http://cmbestpractices.com
©
2013
40
April
9,
2013
20
21. 9/9/13
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
41
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
http://cmbestpractices.com
©
2013
42
April
9,
2013
21
22. 9/9/13
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
43
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)
http://cmbestpractices.com
©
2013
44
April
9,
2013
22
23. 9/9/13
Overengineering
the
Build
• Beware of overly complex builds
• Don't embed calls to the version
control tool
• Use components that can be run
separately
• Automate everything
• Treat this like any other development
effort
http://cmbestpractices.com
©
2013
45
April
9,
2013
Continuous
Integration
• Framework for structuring the entire
build, package and deploy
• Determine build and integration issue
early in the process
• Should include deployment to a test
environment
http://cmbestpractices.com
©
2013
46
April
9,
2013
23
24. 9/9/13
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
47
April
9,
2013
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
48
April
9,
2013
24
25. 9/9/13
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
49
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
http://cmbestpractices.com
©
2013
50
April
9,
2013
25
26. 9/9/13
DevOps
• Set of Principles where development
and operations partners
• Better communication
• Knowledge sharing
• Moving build and deploy upstream
http://cmbestpractices.com
©
2013
51
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
http://cmbestpractices.com
©
2013
52
April
9,
2013
26
27. 9/9/13
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
unauthorized changes (e.g. ports open)
http://cmbestpractices.com
©
2013
53
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
http://cmbestpractices.com
©
2013
54
April
9,
2013
27
28. 9/9/13
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
55
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
http://cmbestpractices.com
©
2013
56
April
9,
2013
28
29. 9/9/13
Using
Tokens
• Your code should read $DB1
• Substitute the correct database
• Centralize environment variable
assignment
http://cmbestpractices.com
©
2013
57
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
http://cmbestpractices.com
©
2013
58
April
9,
2013
29
30. 9/9/13
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
59
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
change
• A priori change control
http://cmbestpractices.com
©
2013
60
April
9,
2013
30
31. 9/9/13
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
61
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
http://cmbestpractices.com
©
2013
62
April
9,
2013
31
32. 9/9/13
Types
of
Change
Control
• A priori
• Gatekeeping
• Configuration Control
• Change Advisory Board
• Emergency Change Control
• Process Engineering
• Senior Management Oversight
http://cmbestpractices.com
©
2013
63
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
http://cmbestpractices.com
©
2013
64
April
9,
2013
32
33. 9/9/13
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?
http://cmbestpractices.com
©
2013
65
April
9,
2013
Minding
the
Process
• Software Engineering Process Group
• Senior Management
• What makes something an
emergency?
http://cmbestpractices.com
©
2013
66
April
9,
2013
33
34. 9/9/13
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
67
April
9,
2013
e-‐Change
Control
• Routine changes
• Still requires traceability and
transparency
• Good way to implement the change
advisory board (CAB)
http://cmbestpractices.com
©
2013
68
April
9,
2013
34
35. 9/9/13
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
• Identify and manage risk
http://cmbestpractices.com
©
2013
69
April
9,
2013
Retrospective
• After action review
• Need open and honest evaluation
• Opportunity to improve the process
• Drives the entire release process
http://cmbestpractices.com
©
2013
70
April
9,
2013
35
36. 9/9/13
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
and deploy releases
• Don't forget being able to rollback!
http://cmbestpractices.com
©
2013
71
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
http://cmbestpractices.com
©
2013
72
April
9,
2013
36
37. 9/9/13
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
73
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
http://cmbestpractices.com
©
2013
74
April
9,
2013
37
38. 9/9/13
Release
Maps
• Complete list of release contents with
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
75
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
http://cmbestpractices.com
©
2013
76
April
9,
2013
38
39. 9/9/13
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
77
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
http://cmbestpractices.com
©
2013
78
April
9,
2013
39
40. 9/9/13
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
79
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
http://cmbestpractices.com
©
2013
80
April
9,
2013
40
41. 9/9/13
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
81
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
http://cmbestpractices.com
©
2013
82
April
9,
2013
41
42. 9/9/13
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
83
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
http://cmbestpractices.com
©
2013
84
April
9,
2013
42
43. 9/9/13
Smoke
Testing
• Last step of the deploy is always
testing
• CM should be part of the QA and
testing function
http://cmbestpractices.com
©
2013
85
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
http://cmbestpractices.com
©
2013
86
April
9,
2013
43
44. 9/9/13
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
87
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
colleagues
http://cmbestpractices.com
©
2013
88
April
9,
2013
44
45. 9/9/13
Let's
Talk
About
Agile
Agile shifts the focus...
(But you will also see that there will be
much in common)
http://cmbestpractices.com
©
2013
89
April
9,
2013
Goals
of
Agile
CM
• Rapidly build, package and deploy
• Reliable and repeatable process
• Traceability and forensics
http://cmbestpractices.com
©
2013
90
April
9,
2013
45
46. 9/9/13
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 Sustainability and Speed by
Mario Moreira
http://cmbestpractices.com
©
2013
91
April
9,
2013
Agile
on
CM
But we really need to use Agile
principles to implement Agile CM
http://cmbestpractices.com
©
2013
92
April
9,
2013
46
47. 9/9/13
Agile Configuration Management
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
http://cmbestpractices.com
©
2013
93
April
9,
2013
Characteristics
of
Agile
CM
• Customer centric (which one?)
• Rapid iterative development
• Pragmatic approach to requirements
• Support for testing
• Collaborative communication
• Role in the SCRUM
http://cmbestpractices.com
©
2013
94
April
9,
2013
47
48. 9/9/13
More
to
Agile
CM
than
just
CI
• Continuous Delivery
• 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
95
April
9,
2013
Agile
Focus
On
Seven
Items
1.
2.
3.
4.
5.
6.
7.
Source Code Management
Build and Release Engineering
Environment Configuration
Continuous Integration
Continuous Deployment
Verification and Validation
Devops
http://cmbestpractices.com
©
2013
96
April
9,
2013
48
49. 9/9/13
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
97
April
9,
2013
Build
in
the
Cloud
• Virtualization allows you to create a
fully 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”
builds and purge unneeded builds
http://cmbestpractices.com
©
2013
98
April
9,
2013
49
50. 9/9/13
Architect
Your
Build
for
CM
• Architect Your Application to facilitate
CM (e.g. immutable version 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
99
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
100
April
9,
2013
50
51. 9/9/13
Puppet/Chef
• Automate provisioning, patching and
configuration of operating system and
application components
• Systems integration framework
• Scalable and extensible
• Used in other deployment frameworks
www.puppetlabs.com www.opscode.com
http://cmbestpractices.com
©
2013
101
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
102
April
9,
2013
51
52. 9/9/13
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
103
April
9,
2013
Deployment
Pipeline
A deployment pipeline is … an
automated implementation of your
application’s build, deploy, test and
release process
Jez Humble and David Farley’s
Continuous Delivery, p 3.
http://cmbestpractices.com
©
2013
104
April
9,
2013
52
53. 9/9/13
Aim of the Pipeline
• Makes building, deploying, testing and
releasing software visible to everyone involved
• 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
will through a fully automated process (p. 4)
http://cmbestpractices.com
©
2013
105
April
9,
2013
Antipatterns
• Deploying Software Manually
• Deploying to Production-like
environment only after Development is
complete
• Manual Configuration of Production
Environments
Continuous Deployment, p. 7 – 10
http://cmbestpractices.com
©
2013
106
April
9,
2013
53
54. 9/9/13
Verification & Validation
• Deming – build quality in
• Test your own framework
• Configuration Audit
• Consider the ergonomics of your
automation
http://cmbestpractices.com © 2013
107
April
9,
2013
Ergonomics
of
Build
&
Release
• Cockpit of a plane
• Controls are easy to read
• Traceability
• Designed to avoid mistakes
http://cmbestpractices.com
©
2013
108
April
9,
2013
54
55. 9/9/13
Devops
• Synergy of Agile & ITIL
• Full lifecycle approach
• Good communication to all stakeholders
• Break down barriers
• Don’t forget separation of roles
http://cmbestpractices.com © 2013
109
April
9,
2013
Dev/QA
Focus
• Development
• QA & Testing
• Operations
• Self Managing/Organizing Teams
http://cmbestpractices.com
©
2013
110
April
9,
2013
55
56. 9/9/13
What
is
DevOps?
• New Term for...
• Portmanteau
• Agile Systems Administration
• Agile Operations
• Group of Principles
Now that we cleared that up!
http://cmbestpractices.com
©
2013
111
April
9,
2013
New
Term
• Group of concepts
• Been around for a while
• Use case is compelling
• Stimulating discussion
• Necessary to meet demand
http://cmbestpractices.com
©
2013
112
April
9,
2013
56
57. 9/9/13
Portmanteau
• Combination of two words
• Development
• Operations
Development and Operations have
very different goals
http://cmbestpractices.com
©
2013
113
April
9,
2013
Conflict
Between
Dev
&
Ops
• Development focused on delivering new
functionality
• Operations is focused on providing
continuous (reliable) services
• Manage risk!
One time I was asked to break the rules
http://cmbestpractices.com
©
2013
114
April
9,
2013
57
58. 9/9/13
Trying
to
make
the
deadline
• Trading system was tested and
passed
• Few bugs discovered
• I was asked to deliver a different
version than was tested
How does DevOps help balance?
http://cmbestpractices.com
©
2013
115
April
9,
2013
DevOps
is
also
• Emerging Best Practices
• Collaboration between Dev & Ops
• Application and Systems Deployment
• Software and Systems Development
But is DevOps Agile?
http://cmbestpractices.com
©
2013
116
April
9,
2013
58
59. 9/9/13
What
about
Agile?
• Agile Systems Administration
• Agile Operations
• Waterfall needs DevOps too!
Release Antipatterns...
http://cmbestpractices.com
©
2013
117
April
9,
2013
Release
Antipatterns
Deploying software manually
l Deploying to a production-like
environment only after development is
complete
l Manual configuration of production
environment.
l
So what really is DevOps?
http://cmbestpractices.com
©
2013
118
April
9,
2013
59
60. 9/9/13
DevOps
is
Really...
• Developer and Operations
collaboration
• Crossfunctional team
• Knowledge Management
• Better communication
Time to get rid of silos
http://cmbestpractices.com
©
2013
119
April
9,
2013
Dev/QA
Focus
• Development
• QA & Testing
• Operations
• Self Managing/Organizing Teams
http://cmbestpractices.com
©
2013
120
July
15,
2013
60
61. 9/9/13
Agile
Focus
On
Seven
Items
1.
2.
3.
4.
5.
6.
7.
Source Code Management
Build and Release Engineering
Environment Configuration
Continuous Integration
Continuous Deployment
Verification and Validation
Devops
http://cmbestpractices.com
©
2013
121
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
122
April
9,
2013
61
62. 9/9/13
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
123
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
124
April
9,
2013
62
63. 9/9/13
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
125
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
http://cmbestpractices.com
©
2013
126
April
9,
2013
63
64. 9/9/13
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
127
April
9,
2013
Which
Standards?
• IEEE 828 – CM Planning
• EIA 649-B – Non compliance
• ISO 90003 to support QMS
• Full lifecycle ISO 12207
Tailor !
http://cmbestpractices.com
©
2013
128
April
9,
2013
64
65. 9/9/13
Moving
Upstream
• Dev to CM to QA to Ops
• Cross functional focus
• Speed up development
• Build a great deployment architecture
• Give it to Devs as a service!
http://cmbestpractices.com
©
2013
129
April
9,
2013
Frameworks
• ITIL v3 including CMDBs, federated
CMDBs, CMS, DML…
• Cobit for SOX
• CMMI ->>>> Agile
http://cmbestpractices.com
©
2013
130
April
9,
2013
65
66. 9/9/13
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
131
April
9,
2013
Assessment
• First step is to assess current
practices - “As-Is”
• Compare to industry standards and
frameworks
• Determine “To-Be”
• Create a plan for improving your CM
processes
http://cmbestpractices.com
©
2013
132
April
9,
2013
66
67. 9/9/13
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
133
April
9,
2013
Configuration
Management
• Configuration Identification
• Status Accounting
• Change Control
• Configuration Audit
Tracking and Controlling Changes to
Configuration Items
http://cmbestpractices.com
©
2013
134
April
9,
2013
67
68. 9/9/13
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
135
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
136
April
9,
2013
68
69. 9/9/13
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
http://cmbestpractices.com
137
CM Best Practices Consulting © 2013
69