Smarter ideas worth writing about.

ALF—No, not the '80s Sitcom

Application Lifecycle Management (ALM) is a set of tools and methodologies for integrating, coordinating, and managing the various stages of software development and delivery.  Cardinal often coaches clients on the setup and use of ALM tools such as source control, backlog tracking, and continuous integration servers.  For customers that don't have the resources to host these services, we even host them at Cardinal - this scenario happens quite often, especially for our growing mobile development work where we often need to ramp up these tools quickly. 

For iOS, Android, and Custom Java Development, our teams use Agilo for backlog and scrum tracking, SVN and/or GIT for source control, and Jenkins for continuous integration (our Microsoft-oriented teams utilize the Visual Studio suite of tools).  We adopted these technologies over several years and, as a result, provisioning was mainly a manual process.  Actually, the process evolved into our old ALM provisioning tool: "Call Rusty".  This is Rusty: 

Rusty would perform his magic on the various systems that host our ALM applications.  Now, Rusty is always eager to help out and I like talking with Rusty, but this process really isn't scalable.  


This year, we set out to document and automate our ALM provisioning process to scale our needs across five offices and several hundred developers.  We call this project ALF.

Now, you might be wondering "I thought we were talking about ALM?  What does ALF stand for?".  Well, the developers didn't think ALM was a cool acronym and wanted a something different, so they chose ALF, which stands for Application Lifecycle Foundations.  This is ALF:

Yes, the furry, cat-eating alien from the '80's sitcom.  I'm surprised any of the developers are even old enough to know what ALF is!  Actually, ALF is a web application that allows any Cardinal associate to provision any or all of these supporting applications from a single interface.


ALF is comprised of two components: the Master Control Program (yes, this is a Tron reference) and one or more Agents.  The Master Control Program contains the HTML and JavaScript for the user interface (UI) as well as the REST web services that support the UI.  Agents are applications deployed on the servers that host the various tools (again, Agilo, SVN, and Jenkins). The agents receive commands from the Master Control Program to create and delete instances of these tools for a given project.   Below is a diagram of ALF as well as a description of the various components and frameworks used it its construction: 

Master Control Program

This application is a traditional JEE application leveraging many of the more common components in the Spring framework.  Authentication is handled by Cardinal's Active Directory via Spring Security. Spring MVC controllers handle REST/JSON services for the UI.  Project related data is stored in MySQL and all SQL interaction is done via Hibernate.  Spring Data allows us to easily communicate with Agents via another layer of REST/JSON services. 

We try to treat these internal projects like customer projects.  For example, we use Test Driven Development (TDD) as much as possible.  For TDD, we used jUnit, Mockito, and DBUnit on the Java side and Karma, Jasmine, and PhantomJS on the UI side.  All of this testing was continually done via our own internal Jenkins CI server and managed by Maven.

User Interface

The UI, a single-page web application, was developed with Bootstrap and AngularJS.  All interaction with the server-side components is done via REST/JSON services. 


Again, an Agent is an application deployed on a machine that hosts one of the ALM applications.  For example, in our internal environment we may have three different servers hosting SVN, two that host Jenkins, and two that host Agilo.  An Agent is deployed to each of these servers and is configured with information about what ALM services are hosted on that machine.  When the Agent comes online, it communicates with the Master Control Program in order to register the services available on that machine.  Once registered, the Agent can now accept commands to provision the services available on that machine.  For a new project, the user can select which services to use and and what systems those services should be provisioned.  Additionally, the user can add new services to existing projects already provisioned by ALF. Finally, once a project has run it's course, it can be easily decommissioned and deleted from ALF.

The Agent was written using Node.js and the Express Framework for Node.  Express allows for easy development of REST/JSON services and NodeJS has built in function for calling shell scripts for configuring our ALM services.  


Native and web-based mobile development are additional strengths and areas of expertise at Cardinal.  Since our web UI is already leveraging REST/JSON services, adding mobile clients is easy.  Currently, Android and iOS clients are under development with plans to add web-based mobile clients.


ALF has been a success on many levels.  From a training perspective, it gave junior developers hands-on experience with tools and frameworks that our industry uses every day (for example, Spring, Hibernate, and Maven).  Additionally, ALF gave us the opportunity to explore newer technologies (for example, Node.js, AngularJS, and PhantomJS).  There were lessons along the way too.  For example, we thought using MongoDB would be a cool tech to try out as a data store.  Although MongoDB is really powerful and easy to use, we found it wasn't really a good fit for what we needed, so we swapped it out for MySQL. ALF allowed our more senior members to mentor in the use of these tools and best-practices.  Finally, project ALF produced a very useful tool that we can leverage internally and for our clients.


About The Author

Enterprise Java/Mobile Solutions Practice Manager
Scott is passionate about Enterprise Application development, mobile web, and native mobile development for iOS and Android.