On Tuesday, November 12, as part of a company wide initiative to bring all corporate websites under the OpenText brand, the Community will be down briefly around 11am Eastern / 8am Pacific as we transition to a new domain name.  The community will be offline while we make the change and when it comes back online it will be located at community.opentext.com and the old domain will redirect to this new location.  Thank you for your patience as we make this important change.

Wikis - Page

Common or Shared Code in Dimensions CM (Part 1 of 3)

0 Likes

This is part 1 of a 3 part series. 

Best Practice

There is no such thing as best practices. Two different teams approaching the same challenge might succeed with completely different approaches.  What works well for one team may well be irrelevant for the other.  What helped one team might be counter-productive for the other.

So think of the above paragraph as my disclaimer. With that out of the way, let’s proceed. ッ

Overview

Maintaining common or shared files that are used across multiple development efforts can be challenging.  There are many ways to configure Dimensions CM to support this. 

In this 3 part series, I will talk about the pros and cons of two different scenarios so that you can decide which approach to take. Remember that one size does not fit all; hence the reason why Dimensions CM is so adaptable and can support different processes.

At the end of each scenario, I will include how to configure Dimensions CM to support that particular scenario.

Before we get started, let’s cover some terminology and a few ground rules to avoid confusion.

 

Terminology

For the purpose of this post, we will assume the common or shared files are not classified as shared “libraries” which would be better handled by the build system at compilation. The shared or common code can be self-contained modules such as a calculator; they can be static files like images, stylesheets, etc for consistent corporate branding; or they can be as simple as scripts used across different applications. 

Common or shared is a term used to describe files that are utilized by one or more applications. An important distinction is whether the files are libraries or source code files because one is pre-compiled while the other is not.

Think of libraries as a collection of mini-programs that are pre-compiled. JAR files, DLLs, Mac OS frameworks, etc. are examples of libraries. They are linked or referenced by the application source code during compilation. We will not get into the distinctions of dynamic vs. static. For simplicity, we will assume that the binding is controlled at compilation by the build tool. In other words, the burden of "sharing" is shifted from the SCC system to the build system where it belongs.

For this post, code is defined simply as source code. A file. It is what developers create, maintain, and enhance. The “what” can be for applications, projects, modules, or libraries. Yes, libraries before compilation should be treated as source code. In Dimensions CM terms files are the items.

For this post, Common is defined simply as a module. A group of files or executables. They can be stand-alone or only useful when combined with applications. 

For simplicity this post refers to applications as your development projects. These can be web applications, desktop applications, etc. Any business application that you are working on. They consume or use Common modules.

Background

Let’s say we have a fictitious company called Qlarius. The Qlarius development team works on multiple applications (App1, App2, App3, … Appn) that share common code called “Common”. This shared code, Common, is forever changing and is under constant development.

To make things more challenging, the Common code is platform specific. Meaning, some Common code are for Windows applications only, some are for Linux applications only, and some code can be utilized for all platforms.

The process configuration also must consider the following areas:

Identification:

  • Allow user to easily identify Common code that is for Windows only, for Linux only, and cross-platform.
  • Allow user to identify Common code from the Application code.

Selection:

  • A Windows Application will not necessarily utilized all the Windows Common code.
  • Just because an Application uses a Common module, it may only need a sub-set of the module’s files.
  • Users will need the ability to decide what Common code to include in their Application development.

Control:

  • Users will need the ability to decide when to update their Application with an updated version of Common code.

Consistency:

  • Need to ensure that the same revision of a Common code is carried through to QA, Test, and Production that was used in Development for a particular Application.

 

Scenarios in Dimensions CM

Two scenarios have been identified with each having their own advantages and disadvantages. 

  • Scenario 1: Keep a copy of Common with every Application.
  • Scenario 2: Reference every Application to Common.

In these scenarios the Developers will be working on the same set of application code for a common purpose such as a sprint, a feature, a patch, or a release. They will be delivering these changes to the repository using the copy – modify – merge approach; in other words using streams. Each Developer is responsible for integrating, building and testing their changes locally before delivering them to the repository.

So let’s explore at a high level what the layout or setup would like in Dimensions CM; how each scenario addresses the requirements listed in the background section above; and the pros and cons of each scenario as it relates to different areas of Dimensions CM such as builds, baselines, and deployments. 

Then we’ll cover a few aspects on key areas around process as they relate to Common: 

  1. Where does the developer make a change to Common code?
  2. How does a developer get a new Common change into their Application Stream?
  3. What version of Common gets tested and deployed to PROD?

 


 

Common or Shared Code in Dimensions CM (Part 2 of 3) --> Scenario 1: Keep a copy of Common with every Application.

Common or Shared Code in Dimensions CM (Part 3 of 3) --> Scenario 2: Reference every Application to Common.

 

 

Tags:

Labels:

How To-Best Practice
Comment List
Related
Recommended