Here’s a rundown of how Integrated Development Environments (IDEs), Source Control Management (SCM) systems, unit testing frameworks, integration build tools, and Continuous Integration (CI) servers ended up as cloud services.

These developer tools were born offline, but when they grew up they moved to desirable residences in the cloud. Here’s a quick run-through of how the old offline software became the new online services.

The developer Stone Age

Long ago, way back in the 20th century, development teams had many tools to help them do their jobs.

While these tools were helpful — and are still in use today — they did not make the development lifecycle a success. Big IT projects took years to complete and often failed, making IT chiefs miserable. More and better tools were required to drag software development out of the Stone Age.

Developers in Toyland

A team of half a dozen software developers has to split up the work into many units. When unit development and testing is done, these units must be integrated into a single deliverable product and tested.

These days, many more tools are available to help a development team with coding. In fact, there are so many tools that it’s almost impossible for any developer to try them all.

  • IDEs help developers write, debug, and collaborate on code, and store code in an SCM. IDEs include Oracle NetBeans, Eclipse, and ActiveState Komodo.
  • SCM systems help developers store code in a central location. One central trunk stores the master copy and many branches store the code being mangled by developers. Apache Subversion, Mercurial, and Perforce are SCMs.
  • Unit testing frameworks help developers test their code. Unit test tools include Test::More for Perl, JUnit for Java, and Selenium for web interfaces.
  • Integration build tools have plenty to do. They fetch software from the SCM, figure out dependencies, compile everything to make the deliverable product, package it up, and even deploy to test servers. Integration tools include GNU Make, Apache Maven, and Microsoft Build Tools.

Connecting the dots

To seriously speed up the software development lifecycle, it’s not enough to use these tools — they must be strung together to make a kind of automated production line. The missing piece of the jigsaw — the system that interfaces with these tools and automates the process — is called a CI server.

Despite the name, CI servers don’t just help with integration testing — they can often be extended with integration build tools, so they can build the test environment, check out and build software, deploy it, and run all the test suites. And CI servers can do this all day, every day.

The CI server that everyone has heard of is Jenkins, but there are plenty more. Others include JetBrains TeamCity, CruiseControl, and Atlassian Bamboo.

Developer tools in the cloud

Many organizations took these tools, added web interfaces, APIs, and payment gateways and provide them as cloud services. Some providers concentrate on doing one thing well, while Platform as a Service (PaaS) providers supply bulging toolboxes to their customers.

IDEs are traditionally used locally, on the developer’s workstation; however, some companies, including Cloud9, Compilr, and Nitrous, want developers to use their hosted IDEs in the cloud.

SCMs have always been a central resource. And you can’t really get more centralized than running as a cloud service. Developers can keep track of their software revisions using services like Atlassian Bitbucket, CollabNet CloudForge, and the big daddy, GitHub.

CI servers are also available as cloud services. Hosted CI has the added challenge of connecting with other hosted services. Codeship, Travis, and Semaphore can all read from GitHub and write to Heroku.

Since developers are the target market of PaaS providers, they all include a CI server in the toolbox they supply to their customers. Microsoft Azure Websites customers can use Visual Studio Online. Red Hat OpenShift Online customers can either deploy a Jenkins CI server or talk to the hosted Travis service.

The story continues

It’s impossible to know just how many software development teams out there have a software toolbox that fits perfectly with the jobs they do. But it’s a good bet there is room for improvement.