The release management practice is at the point where we've developed some application or new service or a new system. And we want to move it out and make it available for those that are going to be the recipients of it and we may push it out to like a server in the environment, but yet it has not been deployed. So we're making the release available and we're going to deploy it at a later time. So when we make a new application or we develop a new system or a tool, we first make it available for use and then we deploy it as a second activity. Part of this activity includes putting together a plan. What we plan to roll out if it's a modification or if it's something that we're adding new, is there any documentation attached to it, and who are the stakeholders that are going to be the recipients of this release. So the release has two parts. We may push it out to a central server and it's available, but then there's a second piece afterwards called deployment. Upon putting together a release plan where we're going to identify what we're going to make available in the infrastructure business environment, included in that release plan are all the components that we plan to add, modify, or remove. The components could include actual configuration items. Well, they may be desktops, they may be printers, they may be scanners, but part of that release package could actually be documentation. As well, it could be cheat sheets or functionality instructions. So part of the release, which could be a release package, could be the component that we're modifying itself. The components that we are touching, it could be training and documentation, it could be steps that the user has to follow in order to use that new release, and then we have methods of which we make our releases available. We can phase in our releases to one team at a time or maybe one floor or one, or one building, we can test it out to a group, and if it goes well with them, then we can roll it out to everyone else. Those methods which you won't be tested on on this foundation exam include waterfall, agile, and DevOps, just for your information purposes. Service configuration management practice is about how I take components of relationships and dependencies on one another in order to deliver an end to end IT service. For example, if your service that you are delivering is email, I don't know if most people know this, but behind the scenes there are multiple components that email resides on. Email is not just an application, it is actually an end to end service. It is a part of an application but in addition to that it resides on a server. It needs communications to be delivered and information to be stored in the cloud, for example. It is something that is managed within a data center and there are security involved at their administration. And all of these components can be diagram. It can be managed by dedicated configuration management team. Their job is to do a discovery of all the components and to learn about how those components relate to one another so those components can be made available to users and stakeholders. Configuration management actually includes a set of activities. That could be a lot of work for the team that has to manage all these components. There actually could be thousands of IT components that an IT organization has to assess and identify and keep track of. It's also part of doing inventory management. But inventory management is just identifying what you have, where configuration management is identifying how the components relate to one another. So for test purposes, you may be tested on a term called a configuration item. A configuration item is any component that needs to be managed to deliver an IT service. So there are multiple components to delivering end to end services. Those components could consist of software, hardware, servers, routers, switches, tools, communication devices, all of those are considered separate configuration items. They all need to be inventoried and they all need to understand the dependencies between each other, because if an email service goes down, the email server is probably affected and you want to identify if you have any redundancy or failover. So it may be necessary to bring this issue up to the financial managers in the organization because you don't want to have just one single point of failure. You want to have some backup. So this team uses tools to assess what the dependencies and the relationships are within the environment so that we can see how it will affect the end to end service. Additional CIs include hardware, networks, and buildings. Any configuration item that impacts the delivery of an IT service needs to be managed. Again, you could have thousands of these components, mice, it could be a monitor, it could be a keyboard, it could be a flat screen. All of these IT components or configuration items need to be managed in some type of database. And the database doesn't have to be a complex tool. You can actually use Excel for this database. But all of these components need to be managed.
