 |
Concept : Understanding Posting, Sharing, and DeploymentFrom $1Table of contents
DescriptionThe entire time you are building your application, you are working and saving your work in your own application work space, or you are checking your work in or out of the depot in order to enable others in your DesignGroup to contribute their own work to the project. Once you have completed an application, there are three staging operations you can perform to make your application accessible for use by others: Understanding Staging ManagementCollectively, these three operations compose Staging Management, and you use the Publish tab to carry out each of these operations. The image below shows(conceptually) the staging management process for deploying an application to the World Wide Web. The process for sharing an application is very similar. The step just prior to both deploying and sharing an application is to post the application to production.
In order to accomplish Staging Management, you must have the proper rights within in a given DesignGroup. Currently, only a person who has SuperAdmin rights (typically the person who created the DesignGroup) can accomplish these operations. In addition, you need to understand the Publish tab interface. PostingPosting is a prerequisite to both sharing solutions and projects, and deploying your completed applicaiton. Essentially, posting a solution or project creates a copy of your application within a staging area called Production, so that you can then either share your your solution or individual project, deploy your finished application, or both. You can create numerous posts of a single solution or project as you add new features or customize an application to create different versions for different customers. SharingSharing is the Staging Management process by which you make a posted solution or project available to other developers, so that they can import and include your code into their own projects. Once you have posted a solution or project, you can choose to place your code into the Share. When posting to the Share, you can select between the Type R or Type E licensing models for your project (see the Bungee Labs Software Publishing Agreement for information about the licenses). When you share a post, best practices dictate that you mark the shared post as Recommended, indicating that this is the version that is up-to-date and the one you recommend developers use in their solutions. You can create any number of shares of a given application as you want, based on updates/improvements to your application. Using Shared PostsFor information on how to incorporate a shared post into your solution, see Using Import and Include Manging Your SharesAfter sharing a post, you can remove it from the Share and change its description. Updating the Shared Posts You're UsingUpdating shared posts is important both if you're a developer sharing your posts or a developer using shared posts of others. If you make changes to or update the posts you are sharing, we encourage you to mark them as Recommended so other developers will know which is the "latest and greatest." If you are using posts shared by other developers, you can quickly check to make sure your application is using the latest version. Changing to a Specific VersionYou may need to select a specific version of a shared post. For example, if you update the shared posts you are using and the latest version "breaks" your application, you can revert to an older version. DeployingDeploying is the Staging Management process by which you make a posted application available to end users. When you complete the process, your application is provided its own space on the Bungee Grid, and you are provided with a URL that you can make available to your end users. Note You can customize how your users access your application. You can make as many deployments of a given application as you want, based on updates/improvements to your application, or if you have an application that you skin differently for different customer sets. The Deployment ProcedureThe general procedure to deploy an application is:
(See the Hello World tutorial in the Learn Tab of the Builder for a step by step example.) Deployment OptionsCurrently, there are two modes of deployment offered:
Test (Free) DeploymentWhen you deploy an application with a Test Deployment, you are given a hard-coded URL in the Bungee Grid and there no charges are accrued. You may deploy in either HTTP or HTTS mode (if you choose HTTPS, Bungee takes care of the certificate for you). Test deployments have the following limitations:
Commercial (Full) Deployment to a Bungee URLCommercially deployed applications require you to establish a billing relationship with Bungee Labs. Deployed applications accrue Bungee Units and you are periodically billed at the current rate. Using this mode of deployment allows you to use HTTP or HTTPS. If you choose HTTPS however, you must provide your own certificates. You can direct users from your own or business Web site through a redirected URL. During Beta phase, deploying live Bungee powered apps is free to developers. Arbitrary URL in CName MappingDuring Bungee Connect's early Beta release, choosing to create a proprietary URL limits you to an HTTP deployment. See this blog post - How To: Use a Custom URL for Your Bungee powered apps. Understanding Deployment ArgumentsAt the time you deploy your application, you can add deployment arguments so that you can easily update a deployment without the need to create multiple deployments of the same application. Common UsesScenarios in which you might want to add deployment arguments might include an application that makes use of live data from a database. During design time (when simulating) you might have a "sandbox" database you access for testing purposes. You could then deploy your application, and add deployment arguments that direct your application to use the proper live database. Note If you want to make use of the same "live" data when you simulate your application as you do when you deploy your application, you can use debug deployment args for accessing your live data from simulate mode. Another example of when you might want to use deployment args is if you are using a web service that requires you to use a different license key for testing as opposed to production use. Adding deployment arguments with the proper runtime key makes your application very configurable. Working with Deployment ArgumentsIn order to make deployment arguments useful, you must also make use of the AppGlobal functionality. In order to do this, you need to add a call function statement, then set the site to AppGlobal. Next, click the ellipsis button [...] and select the getState function. The arguments to getState are key and value. The key is the key you need to give your deployment arguments, and value, is whatever string you enter in the value portion of your deployment argument. See AlsoPosting, Sharing, Deploying, and Managing your Applications Blog Post: How To: Use a Customer URL for Your Bungee powered apps Tags
Tags:
|
