I am wondering how others are making use of Sandboxes within AgileApps?
We have an on premise install of AgileApps.
We have two separate server environments, one for production and one for development and test.
We are going to be creating the Sandbox in the development and test environment. The test environment will be the main tenant, and the Sandbox will be the development environment.
We had been planning on creating one development Sandbox for each tenant, but when I was reading the help wiki for a Sandbox, it seems they recommend creating a Sandbox for each developer. Then each developer would publish to the test environment (main tenant). Here is the pertinent information from the help site:
“Deployment Rules specify the targets (sandbox tenants and the main tenancy) to which a Package can be deployed. In general, you’ll want development sandboxes to be able to publish to each other to share work. You may want one or more sandboxes designated as “integration points” that can publish to the Q/A sandbox, where testing is done. The Q/A sandbox would then be the only sandbox tenancy that is allowed to publish to the production tenancy, so that only a fully tested application is deployed.”
So I am wondering if others are taking the approach of a development Sandbox for each developer, or one Sandbox for all developers to work in?
Also, as far as I know, since we have two separate server environments for test and production, the only way to move an application from test to production is to download the published file from test, and then upload it into production. I just wanted to confirm that.
I ended up talking to a Software AG support person about this situation and here are the answers I received.
According to the support person, most customers who have the on premise version are running on just one server instance. This is production, and then all of the sandboxes they need for development. This is the most common on premise installation scenario.
They do not recommend that each developer have their own sandbox. They recommend there be a single development sandbox and all developers use that.
The way to deploy between two server instances is to download the package file and then upload the package file to the other server instance. In our case, this means downloading the package from our test environment, and then uploading into the production environment.
When you have multiple tenants at different subdomains, all sandboxes are at the “www” domain. In our case, each tenant is on a different subdomain. However, a sandbox created in any subdomain is accessed at the “www” domain. This means that your usernames have to be unique across all sandboxes. This creates a problem if you are using LDAP integration with Active Directory, as there can be only one AD username across all sandboxes. Since we have two physical server environments, this allows us to separate the AD users by environment, so we avoid this issue. So this means if you do AD integration, you must have a separate set of servers for test and production.
Not sure how many customers are running their AgileApps on premise, but wanted to pass on the information I learned from Software AG support.
I talked later with another Software AG support person, and they said for on premise installations that they recommend not using a Sandbox, but rather setting up a separate development and test tenant. We have done this and it has a few implications:
- When deploying an application between development and test environments, you use the download/upload process for the application package. For us, this has the advantage of making the deployment process identical between development–>test and test–>production.
- With separate tenants, you can setup Active Directory integration for each tenant.
If you have a production tenent and an sandbox within it and if you are wishing to share an application from production to sandbox or vice-versa. Then you can share applications without
downloading and uploading the package.
Follow the below steps-
1.Firstly, you have to setup the deployment rules.
->Administration > Account Management > Sandboxes> Deployment rules
select From sandbox and To sandbox to deploy an applications in the way you specify tenents in From and To-sandbox.
- Go to Administration > Account Management > packages ->select package → click deploy button
choose the selected/sandbox tenents and click deploy.
When you log in to the platform, you log into your organization’s tenancy. When you set up a sandbox, you create a “sub tenant” that can interact with the main tenancy, and with other sub tenants.
In a sandbox, you can modify and test an application without changing the production version. You can then deploy the application Package to a Q/A sandbox for testing, or to the main tenancy (the “production” system).