11 Team Concert Behaviors You Should Use for Enterprise Extension (z/OS) Projects

We have worked with several customers in the past few years, and have come to a general consensus on the minimum operation behaviors that should be enabled in your Team Concert project. These that we have listed are in additional to any you may already have (rather than a replacement of them). These also do not include the default behaviors, for which we use the SAFe Program template

most of the time for our Enterprise Extension customers and its default operational behaviors.

Operational behaviors go beyond mere authorization, but rather they check for context about the environment and what you are interacting with. Behaviors can be either preconditions, or follow-up actions.  For all the ones that we recommend listed below, these are found under Team Configuration -> Operational Behavior.

Build

Request Build (server) – Require a Subset in the Build – Fail the z/OS dependency build if it does not contain a buildable subset. We recommend using build subsets as much as possible, especially in environments that are just getting started with a Continuous Integration/Continuous Deployment cycle. This avoids issues where a developer triggers a long running build that blocks build activities required by other users, as well as unintented recompiles of certain modules which are not yet ready for promotion or testing.

Source Control

Save Change Set LInks and Comments (Server) – Restrict Associating to Closed Work Items: Most organizations promote and package at a work item level. As such they track status and approvals on the work items. If a work item progresses to its final status (closed, fixed, etc), and a developer associates a change set to that work item, there is a high chance that the work item will be missed when it comes time to package/promote/deploy those changes.

Save Stream – Prevent Adding User Owned Component : You only have to have one failed build caused by a user-owned new component to realize how much havoc this can wreak. A user owned component should NEVER be delived to a stream. Ever. Even in a distributed environment!

Modify Component – Ensure Component Names are Unique: There are situations where a component may have similar content, but for different purposes. Keeping unique names helps to avoid issues later when a developer delivers code to a wrong stream, or you start using custom Java code, which that opens a whole can of worms with duplicate names.

Deliver (Server) – Require Work Items and Comments: This is usually enabled by default, but in this case we recommend that you enable the precondition for both associating a work item and having a comment. The reason for this is that when multiple change sets get associated to one work item, it become difficult to understand what changes are in each change set. We’ve seen issues where a developer associated a change set to the wrong work item, and it was only latter, and after much analysis that we discovered the errant association. Also, we recommend you use the SERVER version of this instead of or in addition to the client version as you can catch situations that the client precondition doesn’t enforce (e.g. SCM command line, etc.).

Deliver (Server) – Restrict Delivery to Streams: This option should always be enabled for your production stream. Assuming you have a production stream that represents the production build output running in your production environment, you should only be using the Promotion definitions to move change sets into the production stream. Never let a random developer deliver code directly to production, otherwise,  you will cause issues with out of date build maps, out of sync code, and more.

Deliver (Client) Check Language Definition Association on Files: If a z/OS file is not associated to a language definition, it will NOT be built. Period. Thus do not let a developer deliver a new source member if they have not associated it to a language definition (which instructs the build system as to exactly how to compile the member). This is one of the new behaviors and is a welcome change!

Check-in (server) – Restrict Change Set Size: – Restricts the number of changes that can be contained within a single change set. If you only enable one behavior, enable this one. This means that you can associate changes for one source member to only one change set. While you can have many changes in that one member, its limited to ONLY that member. If you have other source members that you are changing, and they need to be linked to the same work item, just put them in separate change sets linked to the work item. Here is the problem if you don’t enable this: If you put multiple changes for multiple source members in a single change set, and then want to promote only the changes for one source member and not others, you will have no way to do it. Its all or nothing, and its irreversible. Yes. You cannot back that out. They MUST all go together, and if you dont’ promote them, then any subsequent member edits will not be able to go either. We’ve seen major issues with this at a client recently. This was as painful as untangling a ball of yarn that had been played with by a litter of kittens. Actually more painful, and less cute.

Promotions

Promotion – Require Work Item States: Typically you promote from a development stream to a pilot or production stream. You only want to promote to those streams once the work for those members is complete, or at least verifiably tested, as indicated by the work item state. This helps to ensure the developers and testers do their due dilligence, and takes that stress off the release engineers and systems programmers who are responsible for kicking off the promotions and deployments.

Promotion – Modify Work Item State: You need to know which work items have been promoted, and don’t want to have to manually change the status of potentially dozens of work items. Let RTC do this for you so the work item state changes to a completed or deployed status.

Work Items

Save Work Item (server) – All Children Resolved: If you are using the Scrum or SAFe template, then you are likely doing User Story based planning. Thus if you want to ensure a story is complete, you need to make sure all the child tasks are complete first. This checks them for you and save you time.

While there are dozens more possible options, we limited this post to just those which have cropped up the most over the past 3 years. You own environment may dictate additional needs, and maybe even differences than what we have above. Use this as a starting point, along with the template defaults.

Of course if you need assistance implementing these or have a need for a custom precondition or follow-up action, we can help there and have built those for other customers as well.