NCR Logical Security Configuration and Deployment Best Practices ...
Configuration Management Best Practices
-
Upload
techwellpresentations -
Category
Technology
-
view
359 -
download
4
description
Transcript of Configuration Management Best Practices
9/9/13
1
Configuration Management Best Practices
1
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
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! 2 April 9, 2013 http://cmbestpractices.com © 2013
9/9/13
2
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 http://cmbestpractices.com © 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 http://cmbestpractices.com © 2013
9/9/13
3
Goals of Code Management
5
• 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 April 9, 2013
Configuration Management
6
• Configuration Identification • Status Accounting • Change Control • Configuration Audit Tracking and Controlling Changes to Configuration Items
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
4
Configuration Identification
7
• 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 April 9, 2013
Status Accounting
8
• 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 April 9, 2013
9/9/13
5
Change Control
9
• 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 April 9, 2013
Configuration Audit
10
• 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 April 9, 2013
9/9/13
6
Ensuring the Trusted Base
11
• 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 April 9, 2013
CM is a full lifecycle effort
12
• 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 April 9, 2013
9/9/13
7
Verification and Validation
13
• Does the CI meet specified requirements?
• Have the requirements for a specific intended use or application been fulfilled?
http://cmbestpractices.com © 2013 April 9, 2013
Functional description of CM
14
• 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 April 9, 2013
9/9/13
8
CM Functions
15
• Source Code Management • Build Engineering • Environment Configuration • Change Control • Release Engineering • Deployment Let's start with a brief overview http://cmbestpractices.com © 2013 April 9, 2013
Source Code Management
16
• 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 April 9, 2013
9/9/13
9
Terminology
17
• 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 April 9, 2013
What is Control?
18
• 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 April 9, 2013
9/9/13
10
Principles
19
• 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 April 9, 2013
More Principles
20
• Processes are repeatable Agile and Lean • Traceability and tracking of all changes • Improves productivity and quality
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
11
Best Practices
21
• 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 April 9, 2013
Sandboxes
22
• 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 April 9, 2013
9/9/13
12
Variants in the code
23
• Supporting multiple operating systems
http://cmbestpractices.com © 2013 April 9, 2013
CopyBranches
24
• Example of a copybranch (versus delta)
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
13
Handling a bugfix
25
• We need to change Revision 2, but 3 is already being developed
http://cmbestpractices.com © 2013 April 9, 2013
Inner Merge
26
• You need to merge the change on the bugfix branch back to the main trunk
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
14
Outer merge
27
• You also might want some new code merged from trunk to the bugfix
http://cmbestpractices.com © 2013 April 9, 2013
Software Patterns
28
• 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 April 9, 2013
9/9/13
15
Streams
29
• 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 April 9, 2013
Examples
30
• 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 April 9, 2013
9/9/13
16
Defect & Task Tracking
31
• 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 April 9, 2013
Globally Distributed team
32
• Managing work for a globally distributed team • Effective communication • Better coordination • Traceability • Visibility
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
17
Defining the Usage Model
33
• 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 April 9, 2013
Training
34
• 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 April 9, 2013
9/9/13
18
Future
35
• More robust Application Lifecycle Management solutions • Integration with the entire ALM • Open standards (OSLC) • Toolchains for everyone!
http://cmbestpractices.com © 2013 April 9, 2013
Source Code Management
36
• Makes everything else easier to manage • Helps to juggle multiple code lines • Improves productivity & quality • Leads us to build engineering!
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
19
Build Engineering
37
• 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 April 9, 2013
Principles
38
• 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 April 9, 2013
9/9/13
20
More Principles
39
• 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 April 9, 2013
CI Identity Crisis
40
• 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 April 9, 2013
9/9/13
21
Version IDs
41
• 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 April 9, 2013
How does this help?
42
• 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 April 9, 2013
9/9/13
22
Compile Dependencies
43
• 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 April 9, 2013
Independent Build
44
• 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 April 9, 2013
9/9/13
23
Overengineering the Build
45
• 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 April 9, 2013
Continuous Integration
46
• 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 April 9, 2013
9/9/13
24
Code Analysis
47
• 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 April 9, 2013
Build Frameworks
48
• Build agents • Preflight builds • Allows use of the build farm • Moves the build framework upstream • Supports rapid iterative development
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
25
Ergonomics of the Build
49
• “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 April 9, 2013
Partnering with Development
50
• 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 April 9, 2013
9/9/13
26
DevOps
51
• Set of Principles where development and operations partners • Better communication • Knowledge sharing • Moving build and deploy upstream
http://cmbestpractices.com © 2013 April 9, 2013
Future
52
• 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 April 9, 2013
9/9/13
27
Environment Configuration
53
• 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 April 9, 2013
Principles
54
• 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 April 9, 2013
9/9/13
28
More Principles
55
• Environment configurations should be changed in a controlled and predictable way • Environment configurations should be documented and understood by all
http://cmbestpractices.com © 2013 April 9, 2013
Supporting Code Promotion
56
• Promotion of code throughout the application lifecycle • Environments must be isolated from each other • QA should never “accidently” access production
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
29
Using Tokens
57
• Your code should read $DB1 • Substitute the correct database • Centralize environment variable assignment
http://cmbestpractices.com © 2013 April 9, 2013
Configuration Control
58
• 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 April 9, 2013
9/9/13
30
Future
59
• 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 April 9, 2013
Change Control
60
• 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 April 9, 2013
9/9/13
31
Principles
61
• 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 April 9, 2013
More Principles
62
• 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 April 9, 2013
9/9/13
32
Types of Change Control
63
• A priori • Gatekeeping • Configuration Control • Change Advisory Board • Emergency Change Control • Process Engineering • Senior Management Oversight
http://cmbestpractices.com © 2013 April 9, 2013
A Priori
64
• 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 April 9, 2013
9/9/13
33
Gatekeeping & Configuration
65
• 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 April 9, 2013
Minding the Process
66
• Software Engineering Process Group • Senior Management • What makes something an emergency?
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
34
The 29 Minute Meeting
67
• Change control meetings can be problematic • Need to be structured and controlled • Entry and exit criteria • Control the dynamics!
http://cmbestpractices.com © 2013 April 9, 2013
e-‐Change Control
68
• Routine changes • Still requires traceability and transparency • Good way to implement the change advisory board (CAB)
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
35
Drive the Entire CM Process
69
• 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 April 9, 2013
Retrospective
70
• After action review • Need open and honest evaluation • Opportunity to improve the process • Drives the entire release process
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
36
Release Management
71
• 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 April 9, 2013
Principles
72
• 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 April 9, 2013
9/9/13
37
More Principles
73
• 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 April 9, 2013
Manifest
74
• 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 April 9, 2013
9/9/13
38
Release Maps
75
• 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 April 9, 2013
My Three Step Process
76
• 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 April 9, 2013
9/9/13
39
Release Coordination
77
• 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 April 9, 2013
Staging
78
• 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 April 9, 2013
9/9/13
40
Future
79
• 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 April 9, 2013
Deployment
80
• 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 April 9, 2013
9/9/13
41
Principles
81
• 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 April 9, 2013
More Principles
82
• 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 April 9, 2013
9/9/13
42
I Make Mistakes
83
• 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 April 9, 2013
Communicating the Deploy
84
• Communication to all stakeholders is essential • Announce outages and completed deployments • Should be automated and part of a console
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
43
Smoke Testing
85
• Last step of the deploy is always testing • CM should be part of the QA and testing function
http://cmbestpractices.com © 2013 April 9, 2013
Current and Emerging Trends
86
• 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 April 9, 2013
9/9/13
44
Changing Landscape
87
• 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 April 9, 2013
Paradigm Shift
88
• 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 April 9, 2013
9/9/13
45
Let's Talk About Agile
89
Agile shifts the focus... (But you will also see that there will be much in common)
http://cmbestpractices.com © 2013 April 9, 2013
Goals of Agile CM
90
• Rapidly build, package and deploy • Reliable and repeatable process • Traceability and forensics
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
46
CM for Agile
91
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 April 9, 2013
Agile on CM
92
But we really need to use Agile
principles to implement Agile CM
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
47
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
93 http://cmbestpractices.com © 2013 April 9, 2013
Characteristics of Agile CM
94
• Customer centric (which one?) • Rapid iterative development • Pragmatic approach to requirements • Support for testing • Collaborative communication • Role in the SCRUM
April 9, 2013 http://cmbestpractices.com © 2013
9/9/13
48
More to Agile CM than just CI
95
• 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 April 9, 2013
Agile Focus On Seven Items
96
1. Source Code Management 2. Build and Release Engineering 3. Environment Configuration 4. Continuous Integration 5. Continuous Deployment 6. Verification and Validation 7. Devops
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
49
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
97 http://cmbestpractices.com © 2013 April 9, 2013
Build in the Cloud
98
• 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 April 9, 2013
9/9/13
50
Architect Your Build for CM
99
• 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 April 9, 2013
Lessons From ITIL
100
• Configuration Management Database (CMDB) • Federated CMDB • Configuration Management System • Definitive Media Library (DML) Devops = Agile + ITIL
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
51
Puppet/Chef
101
• 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 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
102 http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
52
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
103 http://cmbestpractices.com © 2013 April 9, 2013
Deployment Pipeline
104
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 April 9, 2013
9/9/13
53
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)
105 http://cmbestpractices.com © 2013 April 9, 2013
Antipatterns
106
• 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 April 9, 2013
9/9/13
54
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
108
• Cockpit of a plane • Controls are easy to read • Traceability • Designed to avoid mistakes
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
55
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
110
• Development • QA & Testing • Operations • Self Managing/Organizing Teams
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
56
What is DevOps?
111
• New Term for... • Portmanteau • Agile Systems Administration • Agile Operations • Group of Principles Now that we cleared that up!
http://cmbestpractices.com © 2013 April 9, 2013
New Term
112
• Group of concepts • Been around for a while • Use case is compelling • Stimulating discussion • Necessary to meet demand
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
57
Portmanteau
113
• Combination of two words • Development • Operations Development and Operations have very different goals
http://cmbestpractices.com © 2013 April 9, 2013
Conflict Between Dev & Ops
114
• 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 April 9, 2013
9/9/13
58
Trying to make the deadline
115
• 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 April 9, 2013
DevOps is also
116
• Emerging Best Practices • Collaboration between Dev & Ops • Application and Systems Deployment • Software and Systems Development But is DevOps Agile?
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
59
What about Agile?
117
• Agile Systems Administration • Agile Operations • Waterfall needs DevOps too! Release Antipatterns...
http://cmbestpractices.com © 2013 April 9, 2013
Release Antipatterns
118
l Deploying software manually l Deploying to a production-like environment only after development is complete l Manual configuration of production environment. So what really is DevOps?
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
60
DevOps is Really...
119
• Developer and Operations collaboration • Crossfunctional team • Knowledge Management • Better communication Time to get rid of silos http://cmbestpractices.com © 2013 April 9, 2013
Dev/QA Focus
120
• Development • QA & Testing • Operations • Self Managing/Organizing Teams
http://cmbestpractices.com © 2013 July 15, 2013
9/9/13
61
Agile Focus On Seven Items
121
1. Source Code Management 2. Build and Release Engineering 3. Environment Configuration 4. Continuous Integration 5. Continuous Deployment 6. Verification and Validation 7. Devops
http://cmbestpractices.com © 2013 April 9, 2013
Skills for CM guru
122
• 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 April 9, 2013
9/9/13
62
CM/Devops
123
• 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 April 9, 2013
Toolsmith/Devops
124
• 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 April 9, 2013
9/9/13
63
IT Governance & Compliance
125
• 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 April 9, 2013
Sox Compliance
126
• 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 April 9, 2013
9/9/13
64
ISO 9001
127
• 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 April 9, 2013
Which Standards?
128
• IEEE 828 – CM Planning • EIA 649-B – Non compliance • ISO 90003 to support QMS • Full lifecycle ISO 12207 Tailor !
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
65
Moving Upstream
129
• 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 April 9, 2013
Frameworks
130
• ITIL v3 including CMDBs, federated CMDBs, CMS, DML… • Cobit for SOX • CMMI ->>>> Agile
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
66
The CM Process
131
• Should be Lean • Processes need to be reviewed • Tailor down or tailor up • More collaboration and consensus building • Use standards and frameworks
April 9, 2013 http://cmbestpractices.com © 2013
Assessment
132
• 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
April 9, 2013 http://cmbestpractices.com © 2013
9/9/13
67
Plan for Improvement
133
• 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 April 9, 2013 http://cmbestpractices.com © 2013
Configuration Management
134
• Configuration Identification • Status Accounting • Change Control • Configuration Audit Tracking and Controlling Changes to Configuration Items
http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
68
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 135 April 9, 2013 http://cmbestpractices.com © 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! 136 http://cmbestpractices.com © 2013 April 9, 2013
9/9/13
69
Configuration Management Best Practices
137
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
CM Best Practices Consulting © 2013