For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
The Itil Community Forum: Forums
ITIL :: View topic - Custom Software Tracking in CMDB
Posted: Thu May 10, 2007 6:19 am Post subject: Custom Software Tracking in CMDB
We currently have CMDB and have been tracking versions of Custom Software being built through Testing, Staging, and Production.
We have a Logical CI called Environment that we use to link Hardware, Databases, and Software to enable us to know what is installed in which environment and what makes up that environment.
Question is, does it make sense to track the Custom Software CI through these environments within the CMDB, as in knowing where they are installed, what database they are connected to, or should we just focus on the production environment?
I ask this cause I could see this being hard to manage with many systems.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Thu May 10, 2007 12:46 pm Post subject:
Hello Dsemeniuk,
The answer is, "yes", you do want to track everything that is installed in every environment. The reason is that for SW development, you may have many concurrent versions running in different environments (sometimes even in the same environments) and you'll want to track anything and everything you can, as a Release and it's Changes move from one environment to another.
However, I do understand what you're saying about how hard it is to do. What we do for our clients is to implement a powerful "phone home" strategy that ultimately keeps the CDMB up to date, without human intervention. After all, that is why automation exists, right?
What we've built are the following Phone Home strategies...
- Phone Home when you check source code in/out
- Phone Home when you build
- Phone Home when you deploy/distribute
- Phone Home when you install
- Phone Home when you instantiate
- Phone Home when you run
- Phone Home when tests run (start, finish, pass/fail, etc.)
- Phone Home when you have runtime behavioral errors or critical events
- Phone Home when your application is logging
- Phone Home when you promote/reject Releases and/or Changes
- Etc.
The "Phone Home" concept, in essence, captures critical details about an entire environment, at the time of invocation, through processing, and at it's end, and publishes those details back to master logs and CMDBs. It's something that mature SW shops have been doing for decades. If you're in a modern and competitive environment, virtually nothing you do should be manual anymore and most of what I've described above should be in place, anyhow. These days, even most of the code generation should be automated through code synthesizers. Everything that is automated should be in constant communications with your master Knowledge Management platform (a.k.a. your CMDB).
I guess the other side is, what process do you use to trigger or allow the deployment of custom software to be deployed into each environment, then up to production?
That is the debate around here, right now the teams must submit RFCs to deploy their new versions of their customer code into each environment (Test, Staging, Production) which I think is a bit much as we are in project mode right now, and are getting ready to deploy the new system to the production environment. So there can be many iterations/versions of the custom software being built, so does it still seem reasonable to do doing this?
Being in project mode, what process do you use to start capturing the CIs that are being built?
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Fri May 11, 2007 10:18 am Post subject:
Hello Dsemeniuk,
dsemeniuk wrote:
I guess the other side is, what process do you use to trigger or allow the deployment of custom software to be deployed into each environment, then up to production?
That is the debate around here, right now the teams must submit RFCs to deploy their new versions of their customer code into each environment (Test, Staging, Production) which I think is a bit much as we are in project mode right now, and are getting ready to deploy the new system to the production environment. So there can be many iterations/versions of the custom software being built, so does it still seem reasonable to do doing this?
These are very interesting questions because they highlight how wrongly most infrastructure teams interpret RFCs, Change Management, and ultimtaely Release Management.
From a traditional "Product Development" perspective, which is what most Product Management teams in the world follow, they're usually following a Product Lifecycle format. This means...
The Product comes first
Releases are subconcepts of Products by representing "Versioned Products" (i.e. Product X - Release 1.0.0, Product X - Release 1.0.1, Product X - Release 1.1.0, etc.)
Changes are requests to modify a Product, which are manifested in a specific Release. Therefore, Release 1.0.1 might be composed of Changes A, B, and C.
Now, depending on how advanced your SW development team is, they will either "promote" entire Releases across environments or, for the more advanced, "promote" individual Changes across environments. Promoting Changes is a highly advanced concept because it means that Changes, themselves, are versioned, have dependencies to specific versions of Source Files, and must be managed for dependencies between other Changes. It also applies that all Changes get promoted, rebuilt, redeployed, reinstalled, reinstantiated, re-executed, and reverified in every single environment, before they are promoted to the next environment. This is something that most infrastructure teams are not even close to attempting. Most we talk to don't even understand the complexity of such an environment.
It is very important to know that most "Request for Changes" impact things that are supposed to be engineered and tested, long before they go into your production environment. This means that, technically, an RFC gets created, gets scheduled for a specific Release of a Product, starts to get worked on, and gets marched across testing environments, one environment at a time, as it's rebuilt, redeployed, etc., until it's reverified and approved for the next environment. If done corrrectly, you can watch/track your Changes across "all" environments, something ITIL completely misses and, ultimately, something that is missed by many teams that implement ITIL.
I can't stress enough that if you're not creating and scheduling RFCs "before" they get marched through all environments, you're violating the fundamental principles of a solid SDLC.
One interesting thing that I find is that most infrastructure teams we speak with aren't managing their infrastructures as Products & Services with controlled Releases. They just simply apply Changes directly to Assets, which violates the fundamental principles of a solid SDLC.
So, after all of this and to specifically answer your question about what process is used to trigger the deployment of custom code to each environment, the answer is your "Verification Management" process (critical but not covered, at all, by ITIL). Changes are promoted to the next environment based on rigorous testing and signoff on the testcases for those Changes in that specific environment. Only when the tests are executed successfully and approved, should the Changes be approved for "submission/promotion" to the next environment. Once staged for the next environment, the owning "roles" of the next environment (could be the same people in many companies) should take those Changes and apply them to the new environment, based on the dependencies they have to other Changes. NOTE: Most teams we encounter don't even come close to managing Change dependencies. It's the Verification process that signs off an any step in any process, allowing that step to move its "deliverables" (whatever they may be and Changes in this case) to the next step in the process.
Quote:
Being in project mode, what process do you use to start capturing the CIs that are being built?
The answer to this question is very long. To give you a short insight, it starts with a clearly defined Product Lifecycle that everyone in your organization should be following (if you're interested, contact me off line and I'll give you an example of one we use as a baseline for our customers). The Product Lifecycle acts as a backbone for all activities associated with a Product or Service, from the day of inception to the day of its decommission (possibly many years later) and it includes all iterations of Releases and work done within or outside of those Releases. The steps in your lifecycle should act like a Value Chain and highlight critical activities that everyone must follow. It is also this Product Lifecycle that binds and interleaves all other processes...
Project Management,
Release Management,
Change Management,
Incident Management,
Problem Management,
Build Management,
Deployment/Distribution Management,
Installation Management,
Requirements Management,
License Management,
Document Management,
Contract Management,
Verification Management,
Etc., etc. etc.
Mature enterprises understand that "Product Management" is the backbone of "everything" an enterprise does. It has been for decades and ITIL tends to miss this point, completely. Although, they are finally starting to see the light (in a very minimalistic way) in v3, where they just begin to talk about "lifecycles". One of the biggest reasons there is contention between Infrastructure teams and Product Dev & Engineering teams is because ITIL pitches concepts that violate some bigger picture Product Lifecycle best practices, while Dev & Engineering teams have no choice but to follow PLC & SDLC concepts. This leads to instant conflict.
Anyhow, if you have a solid Product Lifecycle in place, you will have steps in the lifecycle that will ensure that appropriate CIs are following their own creation, modification, and lifcycle rules. So, for example, there might be a step that says "Procure Assets". In this step, an Asset should immediately be registered and marked as submitted for procurement, procured, etc. There will be steps where Assets will be built or even rebuilt in new environments. Every action in every lifecycle step simply triggers an update to the CMDB. In this way, you will capture "everything" that makes sense to capture, including its dependencies to environments, people, places, documents, licenses, contracts, etc. In other words, you'll run IT more like a business...
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
