An RTC source control component as I see it is a logical grouping of files & folders.
When should I use multiple components within a stream in RTC source control?
Method 1:
I have multiple java(Eclipse) projects but I am adding these projects to just one component within a single stream. These projects are packaged into one deployment file.
Method 2:
Each java project be added to its own component within the stream, so the stream will contain multiple components - one component for each java project.
Are there advantages/disadvantages to using one method over the other ?
An RTC component has really the same meaning than an ClearCase UCM component.
The goal, when using multiple component, is to divide your huge set of files into coherent and logical subsets, more identifiable and manageable.
Example of components:
an application (or a autonomous part of an application)
a technical library
a packaged set of file (for release)
Note: in RTC, you can reuse a component (defined in one project area) in another project area (provided both PA are on the same Jazz server).
A Java project can be represented as one component, but certain Java project could be seen as several components (one for the business logic, one for database logic, and so on)
The main criteria when you define a component is:
Will it evolve at its own pace? Can you modify it without having to modify another component?
(If not, that might mean the two set of files are tightly linked, and might be considered as one component).
From there, you must decide if you want to see all components on one Stream (system approach, with every component writable), or just one or two components per stream (depending on the deliveries - dll, jar, ... - produced by the other components): component approach.
For starter, stick with the system approach, simpler at first.
Related
I'm building an application where each of our clients needs their own data warehouse (for security, compliance, and maintainability reasons). For each client we pull in data from multiple third party integrations and then merge them into a unified view, which we use to perform analytics and report metrics for the data across those integrations. These transformations and all relevant schemas are the same for all clients. We would need this to scale to 1000s of clients.
From what I gather dbt is designed so each project corresponds with one warehouse. I see two options:
Use one project and create a separate environment target for each client (and maybe a single dev environment). Given that environments aren't designed for this, are there any catches to this? Will scheduling, orchestrating, or querying the outputs be painful or unscalable for some reason?
profiles.yml:
example_project:
target: dev
outputs:
dev:
type: redshift
...
client_1:
type: redshift
...
client_2:
type: redshift
...
...
Create multiple projects, and create a shared dbt package containing most of the logic. This seems very unwieldy needing to maintain a separate repo for each client and less developer friendly.
profiles.yml:
client_1_project:
target: dev
outputs:
client_1:
type: redshift
...
client_2_project:
target: dev
outputs:
client_2:
type: redshift
...
Thoughts?
I think you captured both options.
If you have a single database connection, and your client data is logically separated in that connection, I would definitely pick #2 (one package, many client projects) over #1. Some reasons:
Selecting data from a different source (within a single connection), depending on the target, is a bit hacky, and wouldn't scale well for 1000's of clients.
The developer experience for packages isn't so bad. You will want a developer data source, but depending on your business you could maybe get away with using one client's data (or an anonymized version of that). It will be good to keep this developer environment logically separate from any individual client's implementation, and packages allow you to do that.
I would consider generating the client projects programmatically, probably using a Python CLI to set up, dbt run, and tear down the required files for each client project (I'm assuming you're not going to use dbt Cloud and have another orchestrator or compute environment that you control). It's easy to write YAML from Python with pyyaml (each file is just a dict), and your individual projects probably only need separate profiles.yml, sources.yml, and (maybe) dbt_project.yml files. I wouldn't check these generated files for each client into source control -- just check in the script and generate the files you need with each invocation of dbt.
On the other hand, if your clients each have their own physical database with separate connections and credentials, and those databases are absolutely identical, you could get away with #1 (one project, many profiles). The "hardest" parts of that approach would likely be managing secrets and generating/maintaining a list of targets that you could iterate over (ideally in a parallel fashion).
My current situation is that I have about 20 different Eclipse product configurations for an RCP-Application, which contain different features. But all configurations share, for example, the same JVM-Args.
The obvious problem here is, that if the JVM-Args change, I have to change them in every single product file.
Now my question: is there a functionality to centralize or generalize identical configurations across multiple product configurations?
I'm working on a project that uses an extremely complex BPMN file, so I've been tasked with seeing if splitting it into multiple BPMNs can be done i.e. have it go from one BPMN file into another. We are using Eclipse's BPMN2 Modeler, are there any ways of doing this outside of implementing a Sub-Process? And is there a way for it to happen as a user carries out tasks rather than right at the start, for instance when the user reaches a certain point in the sequence it jumps to another BPMN, otherwise it does not?
You could use message events to signal to different lanes/flows of your original BPMN.
This would enable you to split the flow into sub-BPMN diagrams which can accept message events to start the sub-flow, and emit message events when they're complete to continue the wider process.
Subprocesses is the best way to split chunks of processes into separate units. Based on your question: "for instance when the user reaches a certain point in the sequence it jumps to another BPMN" that is when you place a sub process activity.
I wonder why you are discarding that approach.
My team is new to developing these things and I came into a project that is defining an over-arching workflow using separate processes that are all defined under the same project. So it appears that right now the processes defined are all discrete units, and the plan was to connect these units together using inputs and outputs.
Based on the documentation it looks like the best-practicey way of doing this would be to define the entire, over-arching workflow using sub-process tasks.
So I wonder:
Is the implementation we've started workable?
or
Should I only have one process unit per one workflow, which defines sub-processes if the workflow is too complicated and has discrete parts?
It's fine to separate out certain parts of the process into its own process, and then call those from some sort of parent process. The task you should use in the parent process is called reusable sub-process, or call activity. It's absolutely fine to have multiple processes in the same project.
I am wondering about 'deliverbl', how important are they for historical purposes or during development? All I know is they are created during delivery and includes activies.
If i am exporting major baselines from Clearcase to different SCM, should I consider 'deliverbl' as major baseline?
There are representing merges (from a child stream to another stream), so:
they should be considered, as they show the code "merged" (with potential conflicts resolved)
but you might have more trouble to export the merge hyperlink which shows the source of the merge
I like to export those baselines because their naming convention shows the stream destination name, as well as the date of the deliver, so you are left with clues about a merge between two branches.
However, their are unlabelled, so you might:
either need to convert those to a full baseline (cleartool chbl -full)
or decide to not bother with them and leave those out of your export.