Authored by Kurt Rayner VP, R&D, and Cloud
In many PaaS (Platform as a Service) environments there is either no model for moving through a product release cycle that begins with development, moves to test or QA and then is released as a production deployment. In other environments, there is a rigid “promotion” process that dictates how you must make use of a predefined pipeline.
Alpha Cloud is architect-ed in such a way that you can create and manage your own release process.
This flexibility also means that you can come up with innovative models. You can even have deployments specific to individual customers when using Alpha Cloud to host a SaaS (Software as a Service) application. Here's a look at using Alpha Cloud for your development life-cycle.
Publication versus Deployment
Using Alpha Cloud, the process of moving your application to the cloud, or publishing, deliberately separated from the process of deploying your application to a running web site. As a result, a single published version of your application can be deployed once or many times. You can also select a version of your application and a distinct build of Alpha Anywhere Application Server for IIS and designate it as “development”, “production”, “test” or even “sales demo”. You do this by creating named deployments of your application. Each named deployment is assigned to a web site (and optionally application within the site). Over time, a deployment can reference different versions of your application. We will refer to this as a “pull model” of deployment; meaning that you choose when the version of your application and the build of Alpha Anywhere to pull to a deployment.
Rollback and Roll Forward
Because each deployment can be assigned a separate version of your application and build of Alpha Anywhere, you may have realized that if you need to roll back to a prior version of your application you can simple schedule the deployment with that version. In fact, any deployment can be rolled backward or forward to any version of your application that has been published and any build of Alpha Anywhere that is available.
Subscriptions, Accounts, Applications, and Deployments
To understand what is possible, let’s look at some of the resources that are part of the Alpha Cloud subscription.
When you sign up for Alpha Cloud, you are assigned a subscription. This subscription is an agreement to pay for computing, data transfer and storage resources used. Although a subscription belongs to a specific Alpha Cloud user (called the “owner”), you do not have to have a subscription of your own to use Alpha Cloud. A subscriber may grant other Alpha Cloud users permission to do specific things on their subscription. This is useful for assigning rights and responsibilities to developers and operators on your team or to contract developers.
Within each subscription are one or more accounts. These accounts can be used for tracking usage. Usage reports for Alpha Cloud can be grouped by account. You can also limit access to resources within an account for specific Alpha Cloud users.
Within each account are one or more applications. These are equivalent to web projects. A publish profile would target an application as a way of moving the current web project assets to Alpha Cloud. Each publish operation creates a new version of the application on Alpha Cloud. The versions are retained to support roll-forward and roll-back as discussed above.
Within each application are one or more deployments. Each deployment is assigned to a web site and application path (typically “/” – the root application, but could be “/dev” or something else).
Each deployment has a schedule. Each schedule line associates the deployment with a version of the application as published and a build of Alpha Anywhere Application Server for IIS at a specific point in time (a date/time range).
Subscriptions also have other resources that you manage. For example web sites are owned by the subscription, so there is a good degree of control over who can create a deployment and assign it to a web site. You create a web site by assigning it a name and specifying a region that it should be deployed in. Subscriptions also have security applications (groups of users and roles) that can (optionally) be shared across deployments.
Implementing a Dev/Test/Production Release Process with Alpha Cloud
An application can have any number of uniquely named deployments assigned to different web site/path combinations. The simplest way to implement the release process in Alpha Cloud is to create a deployment for each stage in your pipeline. For example a deployment called “Dev” for development to deploy to for testing, another deployment called “Test” to be used by the QA team and a third deployment called “Production” (you can use any names you choose).
You may want to omit some or to inject additional steps into the cycle. Note that the pipeline doesn’t really exist, these are just arbitrary uses of deployments.
An implemented hierarchy might look something like the following:
Subscription “My Subscription”
Schedule Line 01/02/2018 – (Perpetual) - Version 42 of my application using Build 4770 of Alpha Anywhere Application Server for IIS
Schedule Line 10/01/2017 – 01/02/2018 - Version 40 of my application using Build 4770 of Alpha Anywhere Application Server for IIS
Schedule Line 09/01/2017 – 10/01/2017 - Version 30 of my application using Build 4762 of Alpha Anywhere Application Server for IIS
Schedule Line 01/02/2018 – (Perpetual) - Version 40 of my application using Build 4770 of Alpha Anywhere Application Server for IIS
Schedule Line 10/01/2017 – 01/02/2018 - Version 30 of my application using Build 4762 of Alpha Anywhere Application Server for IIS
Schedule Line 01/02/2018 – (Perpetual) - Version 30 of my application using Build 4762 of Alpha Anywhere Application Server for IIS
Note: This assumes that you create three distinct web sites for the subscription called “dev”, “test” and “prod” respectively. You could also create multiple applications under a single web site (such as “/dev” and “/test”) and put production at the root (“/”). Since accounting is done by usage, there is no cost to the subscriber for additional sites/applications.
Here’s how the process might work:
- 1. An application would be published by the development team.
- · This creates a new version of the application which is now available on Alpha Cloud.
- · That same version could be scheduled to deploy under the “Dev” deployment (this is optional) as part of the publish process.
- 2. Once QA is ready to test a particular version, the responsible individual “PULLS” the version to be tested by added a schedule line to the “Test” deployment.
- 3. Only when QA is confident that a version is ready to be deployed to production, does the person responsible “PULL” that version (and the associated build of Alpha Anywhere) to the “Prod” deployment by adding a schedule line to that deployment.
- 4. Each new iteration would repeat the same process (pulling the version to be tested or moved to production). Note that if necessary, you can roll-back to the previous version using the same “PULL” process.
As you can see, there is no enforcement of any particular approach. You might even create a “demo” site to have a sales team work with separately from production. You might want to create a deployment to verify a prerelease version of Alpha Anywhere. You might have multiple QA deployments to stage multiple versions. In some cases, a SaaS application might have multiple production deployments (one for each customer, or group of customers).
If you customize your application for specific customers, you may want to create a separate application object for each web project variant. Again, each application has its own set of deployments.
The goal of Alpha Cloud, as with all Alpha Software products is to empower you to productively create world-class applications. By supporting you in deploying your way, we give you the tools to create what you need to develop, test and manage your application.
Comment