Cybersecurity
DevOps Cloud
IT Operations Cloud
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.
This is part 1 of a 3 part series.
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. ッ
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.
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.
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:
Two scenarios have been identified with each having their own advantages and disadvantages.
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:
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.