Can we add many Appian objects in a new package by writing some script?

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

Parents
  • 0
    Certified Lead Developer

    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.

  • 0
    Certified Lead Developer
    in reply to k5095

    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.

Reply
  • 0
    Certified Lead Developer
    in reply to k5095

    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.

Children
No Data