UCD components

Editor's Notes

• #5: Components are like containers for artifacts. The PetStore course lab has 3 components.
• #6: For the source config it just defines the source type. The source types used to be baked in and now they are plug-ins. Some of the component fields depend on the source configuration plug-in. Version - Incremental and complete versions. Component properties can be anything you want them to be. Component processes – These do 90% of the work on the component. The application does the other 10% of the work on the component. You run an application to deploy a component. The application process does some of the directing and stuff like that.
• #7: Note that components may be manually imported into UrbanCode Deploy. In the class lab we import the components.
• #8: After you choose the source config type the form changes depending on the source config plugin. You will get different fields. When you create the component, component artifacts go into a repository – if you use codestation (it comes with UrbanCode Deploy, that is where the components go). Usually a component consists of artifacts. If you have file type as the source config type you need to then specify a base path where to find the files. There are about 12 source config types. Only 2 types of component – with zOS the file structures and coding change. But if you are not putting it on the mainframe everything else is the same. A component can be considered a container for artifacts and the processes that operate on them. If you want to use a template you use it there. Then you get a type of component with pre-defined attributes. With a template you can already have processes pre-defined.
• #9: Some fields are shared by all components but some fields are unique depending on the component’s source.
• #12: Source Config Type is a way of specifying where you get artifacts. When artifacts are imported automatically, IBM UrbanCode Deploy periodically checks the artifacts for changes. Whenever changes are detected, a new component version is created. You can control how often artifacts are checked. Source could be DB tables—not every artifact is a file.
• #14: The example used here is of importing a "file system." By importing a file system, the component gets the files it will use. Import implies movement. That's exactly what is happening. The files are moving from the file system to the UrbanCode Deploy CodeStation artifact repository, where they are stored until they are moved again (deployed). In the deployment process, you specify another directory, which is called a working directory, that defines where to place the artifacts during the deployment.
• #15: Usually you do not import versions automatically – you don’t always want new versions. The time interval for polling is set in system settings. You normally do copy to codestation unless you have your own repository. If you use codestation you select copy to codestation.
• #16: There are two types of versions Full and Incremental. With an incremental version the agent compares the incremental version to the inventory and deploys only the changed artifacts. It's not practicle to redeploy entire databases, for instance  Incrementals are used a lot with databases because you do not want to change the whole database. You do not want to replace a whole database every time you have a change. Incrementals are often the ones that are rolled back.
• #17: You have to use some agent to import stuff into codestation. You set this up – you pick an agent to use by default. You can pick an agent with a deployment or by default it uses the system agent. If you choose the second you specify the agent – you are forced to pick an agent. 3rd is you have a bunch of agents and it doesn’t matter which agent does the work - you can select the agent by a tag.
• #18: You usually check the inherit clean up box. That is to use the default behavior. This has to do with how long versions are kept in codestation. You can change the length of time the versions stay in codestation in the system settings. The default is forever. If you have lots of versions that is probably not what you want to do. By default it keeps every version forever. Run process after creating a new version – this is not typically used, normally you would not do this. But if you want you could run a generic process and the trigger might be any time you import a new version. If you have automatic import – it’s a generic process that is kicked off when there is a new version in codestation.
• #21: This is about creating a component version. This is how you manually create a version of a component. You defined parameters of a component and here you give it artifacts. You defined where the artifacts were located but you haven’t loaded the artifacts into codestation yet. This is how you get them into codestation. If we had selected auto version import it would have gone to get the versions. It is better to have a manual import to become familiar with process. In the JPetStore lab there is a manual import.
• #31: Artifacts are not always files – could be a database. It will put all the artifacts into codestation and they will all be in component version 1.3.0.4.
• #34: There are different types of component processes, deployment is the most commonly used. Uninstall takes a component off a resource. It leaves the component but it takes it off a resource. Operational - does not change actual inventory but changes properties. An operational process does not add anything new to the environment. Operational could do something to the environment like start a server.
• #35: Process type - After you import a version, you define the process type that deploys it. The idea is to create a repeatable process that can be reused as new versions of the component are developed. Inventory status - You can make your own statuses – you could have a complicated deployment that goes through different stages in which case you could create your own statuses and direct UCD to use the different statuses but by default there is only one – active.
• #36: This is the location where the agent is going to do the work. The property resolves to an actual spot where the component process does the work.
• #37: This is security – you restrict access to the process by roles that are defined in security.
• #40: The plugins on the left are shipped with the product.
• #43: You do not always have a download artifacts step. But for a deployment process it is the most commonly used step – the agent pulls the artifacts from codestation into the working directory. The default working directory is the location we talked about earlier on slide 35 that the property resolved to.
• #44: To the left you see the Step Palette. The palette provides automation steps that you can drag onto the process editor. The available steps are determined by the installed plug-ins. Some plug-ins are shipped with the product and you can install others.
• #54: Component templates allow you to reuse component processes on a different component – or you could define the properties for any component you create. It could include the component processes or it could not.