Administrative Projects vs. Remote Scripting

When asked about programmatic configuration and manipulation of AnthillPro, I usually recommend remote scripting because AnthillPro's remote scripting interface exposes most of the underlying API, allowing users to:

• extract data from in-house authorization systems and apply that data to AnthillPro projects;
• configure projects based on existing configuration files; and
• run various maintenance and/or reporting procedures.

While this method has been successful, I am always looking for ways to improve. Recently, I decided to approach programmatic work from a different angle, using other capabilities available with AnthillPro 3.5. I was able to use some of the remote scripts as part of an Administrative Project managed by the AnthillPro UI ... with some pretty good results.

Creating an Administrative Project

I used the new Administrative Project approach at a recent installation for an organization that uses a workflow-per-major-branch model, which eventually branches the workflows together to build the master project. To take things further, we could have used scripts that automatically created the necessary workflows for each project. So now, the UI stays tidy because any newly created branch can always be accompanied by one that retires (in AnthillPro, this is called "inactivate") every workflow from the branch being retired.

To set it all up, I first had to create a new Administrative Project. Using AnthillPro 3.5, I created a "Non-Life-Cycle Based"project. (For those of you interested in trying out this approach, you need to be running AnthillPro 3.5 or greater. Prior to 3.5, remote scripting is still the best option). I set up the project with two workflows: one called "Create a Branch" and the other called "Retire a Branch". I also configured each workflow with a manual property for the branch name and a single job step called "Evaluate a Script". For example, the script for the "Retire a Branch" workflow looks something like this:

import com.urbancode.anthill3.domain.project.*;
import com.urbancode.anthill3.domain.security.*;
import com.urbancode.anthill3.domain.workflow.*;

final String WORKFLOW_NAME_PROPERTY = "branch";

ProjectFactory projectFact = ProjectFactory.getInstance();
WorkflowFactory workflowFact = WorkflowFactory.getInstance();
Project[] projectArray = projectFact.restoreAll();
String branchName = PropertyLookup.get(WORKFLOW_NAME_PROPERTY);

for (int i = 0; i < projectArray.length; i++) {
   Workflow workflow = workflowFact.restoreForProjectAndWorkflowName(projectArray[i], branchName);

   if (workflow != null) {
      workflow.setActive(false);;   
   } 
}

The results were pretty good: the organization was happy with the handy little utility project I created for them, not only because it automated many of their manual tasks, but also because it allowed them to keep more configuration within the tool. Now that it is completed, their administrators are now able to quickly retire branches from within the UI by clicking a few buttons. One of the side effects, which I later realized is difficult to gain with remote scripting, is that because everything is logged by the AnthillPro server, managers (and everyone else) are able to maintaining complete traceability.

Since putting this in place, we have used this approach in a number of situations. The kinds of scripts we have written include:

• Custom cleanup algorithms
• Disabling an environment by inactivating agents
• Prior to 3.5's "Force Abort" feature we implemented force aborts as administrative projects
  

A close cousin to these projects are projects that are script based but actually take advantage of the build life infrastructure. An example here is project that is responsible for deploying the latest build of each project in some folder to an early test environment. Running the Deploy secondary process against this again will take the same set of builds to another environment.

To Remote or Not To Remote

Utilizing the new functionality of 3.5, I've found that Administrative Projects are easier to test and maintain, and that execution history traceability is improved. However, Administrative Projects can never completely replace remote scripting. Certainly, any time the API is used as part of another application, the remote scripting interface is the way to go. And though I recommend (and use) Administrative Projects whenever possible, remote scripting is still the best option for acting on input files and/or custom command-line utilities simply because it executes at the command line.