Non-prod instances in Build or Manage domain?

[Alan Prochaska]

Hi all,

The Build domain is described as optional.  You can go right from Design (Business Application) to Manage (Mapped App Service or Service Instance).

We have several pipelines set up so new content goes into Dev, then QA, then UAT, and finally Prod (and DR).

Since Dev, QA, and UAT are about preparing content for production, should all those CIs go into the Build domain?  And keep Manage only for Production and DR?

Interested in thoughts from CSDM mavens.

Thanks for any help!

[Barry Kant]

Hi Alan, 

all environments will be part of the Service Delivery domain, as they are all in operation mode. 
The purpose is different (Dev vs Prod), but they are all operational, and need to be managed. 

The Build domain is the domain before it is moved to operations (Before the pipeline deploys it in operations).
BR,

Barry

[CMDB Whisperer]

I would say "before" could be misleading here.  More specifically, the build domain contains information about the logical components that are individually developed to make up the application service you're building.  So don't think about it as a distinction between non-production and production, and also don't think about it as a transition from non-operation to operation either.  Instead, think about it as a finer level of detail about the individual pieces of technology that the application is built from, and how those individual pieces are built.

[CMDB Whisperer]

CIs don't go into a domain, per se.  These domains are conceptual for describing how the different CI classes are organized and used, and they map to an overall product life cycle, but that is not the same as the promotion stages you are talking about here.  Not sure what you are referring to as "content", as this could be referring to program code or data.  The monikers Dev, QA, UAT and Prod can often describe promotion stages for a specific build of an application ("MyApp build 2.0.123 is currently in UAT"), or they can describe a distinction between different environments or instances of an application with different infrastructure that runs them ("The Dev instance is currently down").  And there can be different "content" (i.e. code or data) that is used and migrated between the different instances to "prepare content for production".  So how does this all relate to CSDM?

As applications are built, these builds may be managed as Product Models which can be versioned, and those Product Models can be associated with other CIs.  However, the individually versioned Product Models do not contain any information about what stage of readiness they are at or what instances currently host those application versions.  That would only be visible in the context of the Services and CIs that are associated to them.  While the Product Models are foundational data in the Foundation domain, they may be associated to the individual SDLC Components in the optional Build domain.

Business Applications (in the Design domain) are version-agnostic, and thus represent all versions of the application that exist. 

Application Services (or Service Instances, in the Service Delivery domain -- previously known as "Manage Technical Services") can be versioned.  That means the Dev instance might contain a different version of the application than the Test instance at any point in time, but those versions will change over time as the application moves through its life cycle and new builds are deployed.  Or in some cases, you may intentionally stand up two different versions of an application as separate instances, such as when you need to support multiple consumers with different compatibility requirements.  If you are preparing content (data) and need to test that content in different environments, then you are simply using the different Application Services to test and migrate your content. 

Finally, Applications are the individual running processes that run on a specific Server, which are part of the Service Delivery System for an Application Service, and are therefore also part of the Service Delivery domain, but they may map to the individual SDLC Components from the Build domain, if you choose to use it.