As detailed in my previous post The AppScan Appliance - Design and Architecture
I noted several components that I consider crucial steps in the
development of the AppScan Appliance Proof of Concept.
One of the
first major milestones will be the creation of a web-based portal where AppScan Source scans can be triggered and the results viewed.
Ideally this portal will be the front
end for a Continuous Integration environment which itself will be
integrated with a Version Control System (VCS) used not only for acquiring
the source code to be scanned but also to upload and archive all
scanning artifacts and results.
In order to keep things open while
incorporating some of the more flexible and powerful open source
technology, I'll be focusing on using Team City as my
Continuous Integration platform and GitHub repositories for
In preparation for the POC, I've set up an EC2 image that I'm using
as a stand in for the mainframe that I'm still trying to get my hands
on. Installed on this image are all the AppScan Products as well as
the common IDEs (VS2008, VS2010, VS2012, Eclipse, etc.), my O2
scripting environment and some other tools of the trade.
So here we go:
The installation of Team City was quite
easy and the configuration relatively so (more on that shortly)...
Here is the AdminWeb Interface for Team City directly after the initial installation:
Creating a test configuration using an Ant build (here you can see the following build step where the actual scan will take place as well):
Now I will set up a GitHub repository to be used as the Version Control System and populate it with a sample application built with Ant:
Next we set up the VCS settings to pull the Source Code from GitHub and also enable storing of the build (and scanning) artifacts in the same repository:
One very cool thing I found with Team City is that it comes pre-configured with most of the typical build scenarios already accounted for. Just choose your poison:
Setting up a Build Trigger upon a Git check-in enables exactly the automated workflow that we are looking for. Ideally we will have a different drop for each type of build and scan that we want to initiate (Java/Ant, Java/Maven, Visual Studio 2005, Visual Studio 2010, Eclipse, make, etc.) and the check-in to the proper folder will trigger the appropriate build configuration. Very cool.
Note: I did end up running into one major obstacle getting the Ant build to run properly... I will detail that problem and solution in depth in a separate post out of respect for separation of concerns.
Below is the screenshot of my 16th build, after powering through the aforementioned configuration sludge, which was finally A SUCCESS!
Although this is just an incremental step in the development of the full AppScan Appliance Prototype, when combined with a Web-based O2 Server Side Scripting environment (allowing for the complex stitching and filtering we need)...we should be well on our way to delivering AppScan On Demand scans by early next week.
Then we'll get into the really cool stuff - and maybe eventually someone will see the possibilities and donate that mainframe I've hinting at...