I want to add 50+ Appian objects to a package. Actually I need to do this activity on a regular interval to prepare deployment package. so is there a way to do it by writing some script or we will have to add each object to package manually only.
I have objects name, type and version with me.
Discussion posts and replies are publicly visible
AFAIK there's no functionality to procedurally add objects of any type to any application or package, beyond that which is provided OOB in the "missing precedents" checker as well as the "Add to App" functionality from the Objects tab. Sometimes it seems like it'd be nice if we had some extended "Add to Package" functionality alongside the "Add to App" button, but unfortunately no such thing exists yet either.
Can you tell us a bit more about your use case? Reading your yet-pretty-vague description, I'm worried you might be somewhat putting the cart before the horse - that is, you've decided in advance to do things in a way that the system isn't designed to handle easily, when there are other approaches that would be far easier to accomplish - though most of us here can't even really guess at suggestions without knowing quite a bit more fine-grained context.
At the time of deploying objects from dev environment to QA environment. I need to create a package which consists of all the objects in dev environment whose latest version is not deployed in QA. I already have a file which contains name, version and type of all the objects that needs to be deployed to QA. So I want to create a package consisting of all this objects in dev environment.
It seems to me as if you're handling this a bit backwards. Generally the usage pattern is more along the lines of, keeping and maintaining a high-level app package that'll contain all necessary objects for an application (minus any precedents that live in higher-level apps like helper or common objects apps), and use that for deploying to other environments, especially / at least for initial deployments, and sometimes also for "catch up" deployments like you describe.
Part of maintaining the app includes ensuring it contains all precedents by routine use of Missing Precedent Checker - to catch and add things which, for example, may have been created in smaller app packages that were created for individual tickets, etc. Any time this is completed, the "compare and deploy" tool can be used to easily test whether there are any undeployed objects between two environments, and if so, which ones, how many, what the differences are, etc.
Yeah to be honest, I can't really see why you would need to do this. If you're going through and defining a list of objects that you want to deploy and holding it in a script outside of Appian, wouldn't it just be easier to add them directly to a package instead? Then when you're ready to go you can directly launch the Compare and Deploy wizard.
Also keep in mind that it isn't that important to specifically identify objects that are changed. If you grab some objects that haven't been changed in your package, when you deploy via Compare and Deploy it will just skip them.
Lets say there are 20 developers in a team and they are all making changes in Appian objects. Now at the end of the month I need to push all the Appian objects that developers changed from dev to QA. So I will have to add this Appian objects to package and then do compare and deploy. so what do you suggest how should I add this Appian objects to package.
We typically do not work like this. We have one shared environment and work on the same application. Deployment is then just one click away.
But that's why you can all collaborate on a package, right? All of those developers can add their objects to the package you're working on as they go and it's easy to deploy everything together.
Even if you didn't do this, it would be pretty easy to identify which objects were created / changed since the last deployment and just filter on all of those objects in the Appian designer. Then, you can add them in bulk to whatever package you need.
One other thing I'd recommend is to look for ways to do more frequent deployments. After the first initial deployment of your entire app, you shouldn't need to wait a month to do another deployment. Instead, you can focus on small, complete increments that can be deployed by themselves. That makes it a lot easier to push your changes up incrementally rather than trying to do everything at once.
thanks Peter, this filtering approach will solve my problem.