Hello Palantir experts,
As you’re aware Palantir doesn’t encourage to create DEV & PROD environments separately, wondering how is this is been handed in the industry with different companies. FYI - git branching strategy doesn’t work end to end to segregate the DEV vs PROD.
For example, given in my flow here, we’ve created some datasets and applying transformations through code repo and creating the intermediary datasets and finally object types in the ontology; Now these objects are being used in function APIs, workshop applications;
When had this already in production, we’ve few more features are in development phase and trying to segregate dev vs prod. i know we can use the git strategy for datasets, code repo and even ontology; but the problem is the downstream applications like function apis, workshop applications do not support dev branch, only master branch.
Do you’ve any best strategies to solve this problem? pls suggest.
Bumping this thread as we’re starting to build out more features and apps in the ontology. We have a use case and a proposed path forward but would love to get some expert opinions.
We are facing much of the same questions:
As we’re building out osdk apps, how do we separate calls to our dev/prod data stack? What are some best practices as to how we build out pipelines and objects, but also be able to utilize them via the osdk libraries in our services without a whole layer of proxy classes?
In our organization, we have two main sets of people that will be utilizing the ontology, with slightly different use cases. Our data analysts are aiming to build Foundry apps on top of the ontology objects. Software engineers are interested in being able to access the same ontology objects use actions via osdk apps, while also developing against lower environments (dev, staging, etc).
We’re considering this approach:
For an object that needs to be accessed by both analysts and engineers, create 2 object sets, 1 with prod data that analysts can build on top of, 1 with prod + dev data that osdks are built on
Example:
We have a concept of a Room.
We will build 2 pipelines:
dev Room pipeline → generates dev Room data set
prod Room pipeline → generates prod Room data set
Both of these data sets then feed into an “engineering” Room object via a pipeline that unions the data sets, adding an additional “environment” field. This engineering Room object will be bundled in an osdk app such that our java services only need to import 1 package. Finally, at run time, any queries that run through the osdk app will include the environment variable as a query parameter.
The prod Room data set is then directly used as the analytics Room object, which our analyst team can then use to build Foundry object views, workshop apps, etc.
