Question about apigee-migrate-tool

[#1]

Our company has been playing around with the apigee-migrate-tool as a way to backup the configuration (proxies, developers, developer api keys, etc). We wanted to have a way to backup all proxies and environments and restore them in the event a planet needed to be rebuilt.

Yesterday, I ran a trial and it pulled in the proxies, apps, developers, environments, orgs, etc. The one thing I noticed is that it did not appear to deploy the proxies to the same environments they were deployed to in the source planet. I wanted to confirm this is the expected behavior. Are there any other configurations that are not recreated with this utility?

[sudheendras]

@Steven Wolfe You need to edit config.js file to specify the Environment where you want to deploy.

module.exports = {

    from: {
        version: 'R22',
        url: 'http://mgmt-server’,
        userid: 'user-id’,
        passwd: 'your-password',
        org: 'your-org',
        env: 'your-env'
    },
    to: {
        version: '14.0.7',
        url: 'http://mgmt-server’,
        userid: 'user-id’,
        passwd: 'your-password',
        org: 'your-org',
        env: 'your-env'
    }
} ;

Thanks, Sudhee

[#3]

Hi Sudhee,

Thanks for the response. I believe I found the root cause of the issue. After confirming my config.js file looked appropriate, I dug a little deeper into the project. Our team had been leveraging the importAll grunt task. This task does not deploy the proxies it merely imports the artifacts.

The bigger issue is that the migrate utility does not appear to be exporting which proxy is deployed to which environment. Without this information, its impossible to restore the environments exactly as they were. You can see in the deployProxies and undeployProxies that they have hardcoded the revision to v1.

Steve

[#4]

Hi @Steven Wolfe,

You cannot replicate the source to the target even if you change the environment in the config.js file.

The problem is if you have a proxy in your source org lets name it as myProxy, and it has three revisions which are 1, 2 and 5 (note there is no revision 3 or 4), and you migrate this proxy to target org, then these revisions will become revision 1, 2, and 3 instead of 1, 2 and 5 (as you would expect), because the Edge won't let you create a specific revision or let you upload a proxy as a specific revision, so that is why cannot replicate your source org.

In Apigee Migrate Tool, you cannot download lower revisions, it will download last revision(let us say revision 10) and deploy it as revision 1, not as revision 10.