Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS Introduction Development In the Cloud: A Practical Use Case Setting Up a Cloud Development Environment

Development In the Cloud: A Practical Use Case

One use case for software development in the cloud combines the agile best practice of continuous integration (CI) and some common collaborative development tooling that has been used across companies of varying sizes, locations, and industries. This approach is scalable and flexible around the size of your development team and type of products you are building.

The cloud development use case encompasses the flow of defects/requirements through phases of development/builds/tests and back to submission of new requirements or defects by various stakeholders. Automation at any point possible is a key capability, including the ability to 'turn on' and 'rip down' virtual or physical systems as needed, in a cloud.

Figure 1 illustrates the workflow for development in the cloud through the perspective of the various contributors, along with their collaborative and cloud management tools.

[Click image to view at full size]

Figure 1: Software development in the cloud workflow and stakeholders.

1. Business Analyst/Quality Engineer (BA/QE) submits defects/requirements.
2. Project Manager (PM) picks tasks, sets priorities, and assigns them to development.
3. Developers open their favorite IDE and view their tasks. They begin to work on the defect and write code.
4. Developers use the cloud-management platform to build and test code.
5. They merge code and change sets.
6. They commit code to a source-code management tool (here, Subversion). This triggers a continuous integration that takes place using the cloud management and build automation tool (Figure 2).
7. CI tool monitors for code changes (Figure 2).
8. Upon build failure, defect tracker is updated and notification is sent to the development team (Figure 2).
9. Upon successful build, the defect tracker is updated automatically. If the test succeeds, test results are e-mailed to PM/QE. If the test fails, QE is notified (Figure 2).

Virtual Private Clouds

So what part of this happens in the virtual private cloud?

• Step 4 is where the developer may configure his own cloud system on demand for build and test.
• Steps 7, 8, and 9--the CI tool and build automation -- run on the cloud systems.
• Once a build is successful, the artifacts are uploaded automatically to the Project Build Library on the cloud systems. The Project Build Library (PBL) stores files created and used by the CI process, which can be shared with others who may need to access the build results.
• A test system can be dynamically provisioned and build artifacts are downloaded and tested automatically.

Figure 2 illustrates what the CI in your private cloud might look like, with virtual and physical machines and tools for source code, tracking, build, and test.

[Click image to view at full size]

Figure 2: Continuous integration in a virtual prviate cloud.

Previous Page | 1 Introduction | 2 Development In the Cloud: A Practical Use Case | 3 Setting Up a Cloud Development Environment Next Page

RELATED ARTICLES Logging In C++ : Part 2 OutSystems Updates Agile Platform SDK, .NET Controls Released for Communications Enabling Web Pages Welcome To the World of Cryptographic Voting recls 100% .NET		TOP 5 ARTICLES No Top Articles.