There’s been significant interest from partners about cloud application development, and we’ve decided to offer a practice-building community around the topic. Just as with the Azure Partner and Office 365 Partner communities, the new Application Development Partner community will include a monthly call, blog series, and Yammer group. Dedicating these assets to Application Development will let the Azure Partner community focus on infrastructure and management.
Our first call is scheduled for September 6, and will cover DevOps. Read my introductory post about this topic, and read part 2, about infrastructure as code.
- Sign up for the September 6 community call about DevOps
- Blog post: Introduction to DevOps
- Blog post: Infrastructure as code
- Join the Application Development Partner Yammer group
In this post, I will talk about the software development practice of continuous integration: what it is, how it applies to Microsoft Azure, and its value to partners.
Introduction to continuous integration
The software development practice of continuous integration is not simply about tooling. Continuous integration brings together all aspects of a software development project and provides a process that increases the flow of work that’s under way. For the purposes of our discussion related to cloud application development, it is the integration of developers and operations personnel to validate that features or changes to the system work, and that they don’t conflict with the work of others. This is accomplished through a process with source control, automated build, and test at its core. The practice of continuous integration allows the identification and addressing of bugs quicker, which in turn allows for improved quality.
The first part of continuous integration is the storage of application, testing, and server code in a code repository. There are several different source code control options available, such as Visual SourceSafe, Subversion, and Git. When multiple teams are working on the same codebase, the source code repository will check for code conflicts when the code is merged back in.
The second part of continuous integration is automated build. When code is checked into the source code repository, a build that may include unit tests is automatically launched that will compile the code and test it for errors. Just as with source code control, there are multiple different options for automated build like Visual Studio Team Services, Jenkins, and Hudson).
Azure and continuous integration
Microsoft has a hosted source code repository and build PaaS service in Visual Studio Team Services, but it is not accessed through an Azure subscription. Organizations that want to host their own continuous integration services can find prebuilt images in the Azure Marketplace. The image at right shows a search in the Azure Marketplace for Jenkins. If a prebuilt image does not work for an organization’s source code or build environment, it’s possible to start from a blank server image or custom image from your on-premises environment.
The partner opportunity
For partners that develop applications or features that are added as a line item on customer engagements, look at continuous integration as something you can offer as a subscription service instead of a single fixed price offer. An example of this is a news aggregation plug-in that you offer every customer you develop an intranet for. Instead of just reusing the code, consider whether it’s possible to package it as a service, and generate recurring revenue.
Take a look at the financial model and value proposition materials below to understand the market opportunity and insights for maximizing profitability.
- Enable Application Innovation – Microsoft Azure financial model
- Enable Application Innovation – Partner value proposition