Whenever I work on a project I like to take the time to put together some scripts or find some tools that can help make my life easier. The cycle of making changes, building, deploying, and testing can be cumbersome if your app consists of a web component, a few services, and a db. One of the ways the Apprenda platform can help improve developer productivity is through automation. Recently while working on an internal application that we have deployed on the Apprenda platform I put together a handful of scripts wrapping ACS functionality to streamline my process.
On the Apprenda platform when you have an application deployed for testing in the Sandbox stage you can demote it back to the Definition stage, update the binaries with a new package, and then promote it again. Sure you can do this by clicking through the Developer Portal UI, but after the a few dozen times within a short period of time you start asking yourself if there is a better way. The answer of course is yes!
The first thing we’ll want to do is automate the creation of the application archive using ACS. Here is the pkg.ps1 script I am using to create the application archive for my app:
The NewPackage command has a lot of options, most of which I did not need for my application. Check out the ACS Documentation for more advanced usages. The above command will rebuild my solution for Debug and dump the resulting archive to $archivepath. Now that we have the archive we can deploy it to our platform. I have already created the application on my platform with the alias of “portal” and the current version alias is “v1”.
Now before we can start managing applications on our development platform we need to register our cloud with ACS. When you log into the Developer Portal you will see the Connecting to your Cloud information on your dashboard. You will need the Cloud URI to register your cloud with ACS.
The following commands will register my cloud with ACS and setup my credentials that will be used while connecting to it:
The RegisterCloud command will simply add your cloud information to ACS and assigns it an alias, in this case “test”, which will be used for other ACS commands. Running acs ConnectCloud will prompt you for user name and password. This is not ideal when trying to wrap ACS in a script so we can leverage the additional options for ConnectCloud to specify our credentials and then tell ACS to remember them using the -Remember option.
First I’ll show you the full script then we can walk through it for better understanding:
In order to make this script reusable I had it take parameters for which cloud to use, what application version to update, along with the path to the archive and an optional user parameter. The script then handles setting up the connection to the cloud, if a user was not specified you will be prompted by ACS.
It then demotes the version specified using the -Y option to force the operation without a confirmation prompt. This will take the specified version out of the Sandbox stage and move it back to the Definition stage.
We then us the SetArchive command to update our application with the specified archive.
Lastly we promote the version back to the Sandbox stage so we can test our changes once again specifying the -Y flag to suppress the confirmation prompt.
Now that we have these scripts we can easily wrap them into a single command:
All this does is invoke the packaging script we created above and then redeploys the created archive to my local cloud. I’ll leave it as an exercise for the reader to refactor these scripts into an even more generic solution that can then be leveraged for any app at any version. There really is very little you cannot automate when it comes to your application management lifecycle.
I hope that you have found this post useful and were able to see the benefits that we can bring to your day to day development tasks.