Integrate Button: Deliver Software at the Click of a Button

Using a Cloud Infrastructure for Software Deployments

In the past couple of years, we've invested heavily into using cloud computing at Stelligent and for our customers. Since we create software delivery systems for our customers, it's been our goal to automate all of these processes and literally click a button to generate software that is ready to go to production. While we were able to automate many build, database assembly, deployment, testing, static analysis and other processes, the assumption was often that an instance of some sort (bare or virtual metal) had been setup. Even those that refer to the benefits of Continuous Deployment often make an assumption that the instance is available and configured. At Stelligent, we no longer make this assumption. We're automating the procurement and provisioning of the instance - including installing and configuring servers - using cloud computing.

Having spoken with several colleagues and at conferences about what we're doing, they thought it might be helpful for others to learn how we're using cloud computing resources on our internal projects and with some of our customers. While we've used various cloud providers, I will focus on Amazon Web Services (AWS) for the purpose of this blog entry.  

AWS - Elastic Compute Cloud (EC2)

EC2 provides on-demand virtual hardware instances using a pay-as-you-go model: you only pay for what you use. This makes it perfect for development and testing. We developed a web-based application that uses EC2 to provision a fully installed tech stack for Continuous Integration and target environments to deploy to our customers' non-production target environments. We are generalizing the functionality and releasing it as our CI as a Service Platform as a Service product in the coming weeks. So, using EC2, developers can use a web application to click a button and provision CI and target environments on demand. Developers are able to create clean target environments on demand when wanting to test a new feature in isolation against the project's technical stack. The application uses the Typica framework to access EC2's API.

AWS - Simple Storage Service (S3)

We're using S3 to store binary files in which we don't need to track multiple versions or for storing software distributions under development that can be recreated from source in other ways. S3 provides a great platform for storing transient files. Moreover, we're excited about utilizing AWS' recently announced S3 Reduce Redundancy Storage to lower our costs for truly transient files. We use tools such as Elasticfox for accessing files in S3. We're also beginning to use CloudFront for managing distributions for users who don't have access to our AWS account.

AWS - Elastic Block Storage (EBS)

EBS is used to attach data volumes that might need to persist after an EC2 instance is terminated. A typical use case goes something like this:

1. Test team uses CI as a Service to provision a target environment
2. Test team deploys/installs working application onto this provisioned target environment
3. Test team stores test data that want to use for future testing
4. Test team terminates the instance using CI as a Service (terminates the EC2 instance)
5. Test team provisions new instance using CI as a Service, installs software and reattaches EBS

Stelligent CI as a Service

Our CI as a Service product started to "scratch an itch" as we wanted to install and configure a complete target environment using a cloud infrastructure. We noticed we were doing basically the same thing each time: procuring the instance, selecting instance specs, selecting the operating system, configuring the OS, installing and configuring servers and tools such as Java, Ant, MySQL, Tomcat, (Hudson in some  cases), etc. So, we wrote a web application to perform the installation and configuration of this tech stack so that we could get a complete deployment environment at the click of a button. Development teams use this service on projects to setup (and terminate) these environments at the click of a button. 

In Summary...

This is meant to be an introduction to some of the cloud computing tools we are using on development projects for ourselves and our customers. It gets really interesting when considering process, usage and other factors when using a cloud infrastructure. Stay tuned for more...

Continuous Integration as a Service Beta Now Available

Deploy working software at the click of a button

We are pleased to announce the release of our CI as a Service product from Stelligent. Using Continuous Integration as a Service, you get running with CI along with a complete development environment stack in minutes and manage it. Moreover, you have full unfettered access to the instance. You can start and stop fully configured virtual instances at any time.

The tool installs and configures the Hudson CI server, MySQL database, Subversion, Ant, Maven, Java and all other necessary tools to create and manage working software at the click of a button. It also runs a one-click build and deployment of working software from source code. At Stelligent, we use the CI as a Service to create working software from our SVN version-control repository - on demand.

See the video that demonstrates how to start using CI as a Service. The basic steps are:

1. Click the "Try it Out" button from the Stelligent website.
2. Enter your email address and password and click the Give me CI button.
3. Review the price information and click the Purchase button
4. You will receive an confirmation page. From this page, you can click the Download Key button to download your private key to access your virtual instance or monitor your CI instances.
5. In about 15 minutes, you will receive an email with links to your provisioned virtual instance and running Hudson Continuous Integration server

At this point, you have a fully-configured CI environment. Moreover, you have full access to this instance to configure as you please. No need to negotiate with your Systems/Operations team or wait for them to provision an environment. Build and deploy your software in a clean environment at a moment's notice. Sign up for the beta of CI as a Service and let us know your experiences with it.

CI as a Service is a product and accompanying service offering from Stelligent. Our CEO literally wrote the book on Continuous Integration. We are passionate about helping our customers automate the entire software delivery process to get software to users more quickly.

There's a big difference between automated and automatic

In our work, we interact with people from many different teams: developers, QA/testers, operations, etc.. In some organizations, operations may be further segmented into SCM, DBAs, Security, and so on. And, in other cases, some functions might be combined. But, if I had a nickel for every time I asked someone whether some process was automated and they incorrectly told me yes, well...you know the rest. This is why definitions matter sometimes. It's the difference between automated and automatic.

What they mean is:

• We wrote some scripts for that
• You have to log into each of the machines separately to run the processes
• Your environment/machine has to be configured just right to run the scripts
• You must manually execute each of the scripts separately
• A human must be present to run the scripts
• It's "automated"
  

What I mean is:

• The scripts are run headless (i.e. from a single command)
• The scripts are checked into the version-control repository
• The scripts have been integrated into the build and/or deployment scripts -- and all processes can be run from a single command
• That the automation is automatic

The difference between the approach they think is automated and what I think is automated is vast. But, it's not about using the right definitions; it's about having a common understanding of the goals you want to attain. The "manually automated" approach leads to significant bottlenecks (real scenario: 100 projects and 10 target environments per project means that your development is stopped every single time someone must manually perform these repetitive activities).

So, the next time someone tells you "(their) stuff is automated", you might want to ask a few questions because each manual task slows down the entire process which costs time, money and frustration.