Apex Code Development You need to sign in to do that
Don't have an account?
soma A deployment nightmare.
I don't know how many people have managed to deploy to their production environment without a single issue in Eclipse, but this process has been a nightmare for me causing me hours of completely unnecessary work, so now I'm going to take some time to write up the crap I've gone through to inform other users as well as Salesforce. Before I say anything else, though, I'd like to propose that Salesforce enable a means to directly transfer code from a sandbox to live within the Salesforce UI with the possibility of not requiring unit testing. Now, on with my story.
I wrote a trigger and a utility class and modified them directly in the sandbox environment without the use of Eclipse. I did most of the revisions in an external editor then copied/pasted those modifications into the sandbox. I performed a variety of tests to prove that my code was working properly without the use of unit tests. When I was ready to deploy my code to the live environment almost THREE WEEKS AGO, I was at a complete loss of what to do. I didn't see any buttons in the sandbox that said "move to live" or anything in the live environment that would allow me to create a trigger by editing code directly (like you can do with s-controls), so I began doing some research. I discovered two paths to deployment: the ANT tool and Eclipse. Honestly, I was opposed to having to use either route. It seemed to me that having to download third party tools to move code from the sandbox to live was a very broken process. I researched using the ANT tool, as there appeared to be more documentation provided by Salesforce for using this tool than using Eclipse, but then I saw a few posts in this community suggesting that using the ANT tool was a very tedious, error-prone process, so I went with Eclipse (version 3.3.1.1). There was almost no documentation provided by Salesforce regarding the use of Eclipse--documentation that did exist for this route was exceedingly sparse and lacks any real substance or troubleshooting information.
So, I started a new Force.com project in Eclipse we'll call Foo. I entered all the credentials and made the "SOAP Endpoint" point to "https://www.salesforce.com/services/Soap/u/11.1", which is the live environment. I figured I could just paste all my code into this new project then save it to live. When the project was created, the first thing I noticed were subfolders in Foo/src that had no value to this project whatsoever; these were subfolders named "AJAX Tools", "crystalreports.com release v1.2", "Financial", and "VerticalResponse for AppExchange". I could only guess these were installed applications/packages in our Salesforce environment, but what were they doing in my project?! I figured, okay, well, this is stupid, but I'll ignore these folders and put everything beneath the "unpackaged" subfolder. I recreated my trigger and utility class, then attempted to "Synchronize with Server", "Save to Server", and "Refresh from Server", but nothing worked. A dialog would pop up saying "Operation in progress..." but then it would close without any information. Nothing was working. I did more research and figured it might have to do with the fact that I wasn't running any tests, so I created a quick testMethod and ran it. Still nothing. I went in and tweaked the project settings, changed the "SOAP Endpoint" to "https://test.salesforce.com/services/Soap/u/11.1" and modified the credentials so I could access the sandbox and magically, all of the Force.com menu options started doing something. So that's great, I thought, now I can manipulate items in the sandbox, but that doesn't achieve anything.
More research led me to trying the test unit route. I figured if I created some code to test my trigger and utility class and achieve full coverage, I'd be past one of the stages of this horrible deployment process. So, I created a new class to house my testMethods and the first testMethod I wrote was to test my utility class. Right-click, Force.com, Run Tests and voila, utility class is 100% covered--it was small, had almost no conditionals, and didn't modify any objects in Salesforce, so 100% coverage for this was trivial. Now, time to test the trigger. Developing the testMethod for this was beyond tedious, causing me days of trouble, and I had other tasks and projects to attend to at work that actually accomplished something. Ultimately, with another pair of eyes examining the test code, I discovered the error was a misplaced 'insert' line. Fortunately, all this time I was running tests, all I had to do was right click in the code of my test class, go down to Force.com, and 'Run Tests'. The test coverage status would display in a pane in the "Apex Code Test Runner" and it applied to both my trigger and my utility class. After finally achieving 100% coverage of the trigger, I attempted the first deploy. First, I was prompted about files not being synchronized so I decided to attmept a synchronization, but because of the presence of some oddities in other files beneath those extra packages, such as "Financial", full synchronization didn't seem to work, so I skipped this and continued with deployment. Second, I encountered problems with the version number, since the sandbox is running 12.0 and this would be written into the meta files for the code, but the live environment is running 11.1, so conflicts arose. Next, I was posed with a deployment plan which had all kinds of references to things associated with the other aforementioned applications, and this was yet another annoyance, but I could safely ignore these inclusions. So, I found the pieces of the plan relating to my trigger, utility class, and test class, checked them, validated deployment, and finally deployed successfully--that was fairly painless.
Then my next nightmare started: I had to change a single literal string value being assigned to a variable in my trigger, so I would have to do this then redeploy. I modified the literal string and ran tests again. This time, however, the code coverage shown in the "Apex Code Test Runner" applied to the test class itself (which makes no sense) and neither the trigger nor the utility class were mentioned. The only way I could get the test class to run against something other than itself was to right click on the "classes" subfolder (i.e. Foo/src/unpackaged/classes), which contained both the test class and utility class, then go to Force.com > Run Tests. The code coverage then showed 100% coverage for both the utility class and the test class. I decided to try a deploy without running the tests directly like this, and when I came to the deployment plan I noticed something very odd: the deployment plan had "Overwrite" options for my trigger and utility class, but they belonged to the "Financial" application and were not in the "unpackaged" category. I exited the deployment dialog and expanded the "Financial" folder and its "classes" and "triggers" subfolders which revealed copies of my utility class and trigger. Now, beneath my project, my trigger and utility class existed both beneath "Financial" and "unpackaged". I selected the copies beneath "Financial" and deleted them, a dialog appeared saying they did not exist on the server so they would only be deleted locally--wonderful. Then I went to issue another deployment. Oops, version issues, have to modify those meta files then deploy again. Came back to the deployment plan (after having to enter my credentials and select a SOAP Endpoint for the deployment for the umpteenth time) and found my trigger and utility class marked for deletion from the Financial package, but there was no mention of "Adding" or "Overwriting" for my trigger and utility class under the "unpackaged" package. So, I ran the deploy, deleted the faux trigger and utility class from "Financial" and attempted to deploy again hoping the plan would display my classes under the "unpackaged"--nothing. Where the hell did they go?
I created another project, pasted my code, attempted to run tests but saw my test class was receiving 100% coverage with no mention of my trigger or utility class, so that's still broken, but I issued a deploy, anyway. Deploy failed saying my trigger was only 35% covered. I examined the test code and discovered a line I must have commented out somewhere in the confusion, then deployed, again. Finally, almost three weeks later, 100% coverage, successful validation, successful deployment.
I shouldn't have to massage a third party IDE to deploy something from the sandbox to live, but I did and needless to say, I'm beyond frustrated.
Message Edited by soma on 03-07-2008 11:54 AM
I wrote a trigger and a utility class and modified them directly in the sandbox environment without the use of Eclipse. I did most of the revisions in an external editor then copied/pasted those modifications into the sandbox. I performed a variety of tests to prove that my code was working properly without the use of unit tests. When I was ready to deploy my code to the live environment almost THREE WEEKS AGO, I was at a complete loss of what to do. I didn't see any buttons in the sandbox that said "move to live" or anything in the live environment that would allow me to create a trigger by editing code directly (like you can do with s-controls), so I began doing some research. I discovered two paths to deployment: the ANT tool and Eclipse. Honestly, I was opposed to having to use either route. It seemed to me that having to download third party tools to move code from the sandbox to live was a very broken process. I researched using the ANT tool, as there appeared to be more documentation provided by Salesforce for using this tool than using Eclipse, but then I saw a few posts in this community suggesting that using the ANT tool was a very tedious, error-prone process, so I went with Eclipse (version 3.3.1.1). There was almost no documentation provided by Salesforce regarding the use of Eclipse--documentation that did exist for this route was exceedingly sparse and lacks any real substance or troubleshooting information.
So, I started a new Force.com project in Eclipse we'll call Foo. I entered all the credentials and made the "SOAP Endpoint" point to "https://www.salesforce.com/services/Soap/u/11.1", which is the live environment. I figured I could just paste all my code into this new project then save it to live. When the project was created, the first thing I noticed were subfolders in Foo/src that had no value to this project whatsoever; these were subfolders named "AJAX Tools", "crystalreports.com release v1.2", "Financial", and "VerticalResponse for AppExchange". I could only guess these were installed applications/packages in our Salesforce environment, but what were they doing in my project?! I figured, okay, well, this is stupid, but I'll ignore these folders and put everything beneath the "unpackaged" subfolder. I recreated my trigger and utility class, then attempted to "Synchronize with Server", "Save to Server", and "Refresh from Server", but nothing worked. A dialog would pop up saying "Operation in progress..." but then it would close without any information. Nothing was working. I did more research and figured it might have to do with the fact that I wasn't running any tests, so I created a quick testMethod and ran it. Still nothing. I went in and tweaked the project settings, changed the "SOAP Endpoint" to "https://test.salesforce.com/services/Soap/u/11.1" and modified the credentials so I could access the sandbox and magically, all of the Force.com menu options started doing something. So that's great, I thought, now I can manipulate items in the sandbox, but that doesn't achieve anything.
More research led me to trying the test unit route. I figured if I created some code to test my trigger and utility class and achieve full coverage, I'd be past one of the stages of this horrible deployment process. So, I created a new class to house my testMethods and the first testMethod I wrote was to test my utility class. Right-click, Force.com, Run Tests and voila, utility class is 100% covered--it was small, had almost no conditionals, and didn't modify any objects in Salesforce, so 100% coverage for this was trivial. Now, time to test the trigger. Developing the testMethod for this was beyond tedious, causing me days of trouble, and I had other tasks and projects to attend to at work that actually accomplished something. Ultimately, with another pair of eyes examining the test code, I discovered the error was a misplaced 'insert' line. Fortunately, all this time I was running tests, all I had to do was right click in the code of my test class, go down to Force.com, and 'Run Tests'. The test coverage status would display in a pane in the "Apex Code Test Runner" and it applied to both my trigger and my utility class. After finally achieving 100% coverage of the trigger, I attempted the first deploy. First, I was prompted about files not being synchronized so I decided to attmept a synchronization, but because of the presence of some oddities in other files beneath those extra packages, such as "Financial", full synchronization didn't seem to work, so I skipped this and continued with deployment. Second, I encountered problems with the version number, since the sandbox is running 12.0 and this would be written into the meta files for the code, but the live environment is running 11.1, so conflicts arose. Next, I was posed with a deployment plan which had all kinds of references to things associated with the other aforementioned applications, and this was yet another annoyance, but I could safely ignore these inclusions. So, I found the pieces of the plan relating to my trigger, utility class, and test class, checked them, validated deployment, and finally deployed successfully--that was fairly painless.
Then my next nightmare started: I had to change a single literal string value being assigned to a variable in my trigger, so I would have to do this then redeploy. I modified the literal string and ran tests again. This time, however, the code coverage shown in the "Apex Code Test Runner" applied to the test class itself (which makes no sense) and neither the trigger nor the utility class were mentioned. The only way I could get the test class to run against something other than itself was to right click on the "classes" subfolder (i.e. Foo/src/unpackaged/classes), which contained both the test class and utility class, then go to Force.com > Run Tests. The code coverage then showed 100% coverage for both the utility class and the test class. I decided to try a deploy without running the tests directly like this, and when I came to the deployment plan I noticed something very odd: the deployment plan had "Overwrite" options for my trigger and utility class, but they belonged to the "Financial" application and were not in the "unpackaged" category. I exited the deployment dialog and expanded the "Financial" folder and its "classes" and "triggers" subfolders which revealed copies of my utility class and trigger. Now, beneath my project, my trigger and utility class existed both beneath "Financial" and "unpackaged". I selected the copies beneath "Financial" and deleted them, a dialog appeared saying they did not exist on the server so they would only be deleted locally--wonderful. Then I went to issue another deployment. Oops, version issues, have to modify those meta files then deploy again. Came back to the deployment plan (after having to enter my credentials and select a SOAP Endpoint for the deployment for the umpteenth time) and found my trigger and utility class marked for deletion from the Financial package, but there was no mention of "Adding" or "Overwriting" for my trigger and utility class under the "unpackaged" package. So, I ran the deploy, deleted the faux trigger and utility class from "Financial" and attempted to deploy again hoping the plan would display my classes under the "unpackaged"--nothing. Where the hell did they go?
I created another project, pasted my code, attempted to run tests but saw my test class was receiving 100% coverage with no mention of my trigger or utility class, so that's still broken, but I issued a deploy, anyway. Deploy failed saying my trigger was only 35% covered. I examined the test code and discovered a line I must have commented out somewhere in the confusion, then deployed, again. Finally, almost three weeks later, 100% coverage, successful validation, successful deployment.
I shouldn't have to massage a third party IDE to deploy something from the sandbox to live, but I did and needless to say, I'm beyond frustrated.
Message Edited by soma on 03-07-2008 11:54 AM
It looks like this post hasn't been updated in a year. I'm still experience the same problem and would love an update since there have been multiple releases and no upgrade like this. Thanks.
All Answers
- Since Salesforce introduced the security token, I haven't messed with it much, but it caused a few applications running outside Salesforce to fail. Instead of using the security tokens, I add IPs to the whitelist in Salesforce. If your IP changes frequently, then I suppose this is an issue.
- Logging into a sandbox environment differs from logging into live. This took me a bit to get even though this is described in Salesforce documentation.
JT - Office 949 856-7877 9:00AM -- 5:00PM EST
Cell 714 813-7318 anytime.
I'm getting a not in Manifest error - Force.com IDE
Thanks.
I am admittedly an Apex newbie (extreme newbie) and I'm in the same boat. I finally figured it out enough to make a small class and trigger work the way I want on my development account. Now I am trying to use Eclipse to move it to our production system and I'm about ready to give up. I continue to get test coverage errors and now I have a couple of empty classes and triggers in production system that I can't figure out how to update or remove.. If I can do it in my development account, why do I need to use a third party tool to create and deploy in our production account? This is VERY Frustrating.
Respectfully,
Brian
We finally got a whole slew of Apex working, and are now pretty handy with the testing & deployment, but it took us a good month or so to learn enough to feel comfy with it. Shallow learning curve it ain't.
And if you keep writing apex, just wait until you start hitting the heap and code line governor limits. That's when the real fun starts!
Message Edited by sparky on 03-12-2008 05:45 PM
As for moving between DE dev orgs and prod, there's no automated process in the app for that, and there won't be for the forseeable future.
sandbox->prod is another story, as the relation exists, but we're not looking to do that in the next few releases. Sandbox copies are currently very low level, and use a different method for copying from prod than the metadata apis use to serialize your setup data. We won't be using it to go from sandbox to prod.
That being said, the plugin and ant tool are being developed on the same team doing the serverside metadata apis (and sandbox dev), and we use the tools internally, so the feedback loop is very small.
If you have particular areas you'd like us to focus on for the deployment doc, please post them here, Mario will note them down.
It looks like this post hasn't been updated in a year. I'm still experience the same problem and would love an update since there have been multiple releases and no upgrade like this. Thanks.