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'm trying to give a field a custom display name value.  I've done this with standard tables before, but I'm using blocksection and am having some trouble.  I tried using outputLable, but it added another row and didn't change the name of the item I had given the ID to.

 

here's the code:

<apex:pageBlockSection columns="1" >
            <apex:inputField value="{!Task.Activity_Type__c}"/>
            <apex:inputField value="{!Task.WhoID}"/>
            <apex:inputField value="{!Task.ActivityDate}" ID="Date"/>
            <apex:inputField value="{!Task.Description}" style="width:50%;"/>
        </apex:pageBlockSection>

Is it possible to give the "Date" field a new display value?

 

Thanks in advance!

We have a custom object that isn't a child object, but is related to leads, and once converted, opportunities.  I've set it up so that the Converted Opportunity ID is mapped into the custom object, but I'm not seeing a way to populate that as a lookup.  We need to have the custom object move through our sales process as it is related to both lead and opportunity.  We're trying to avoid using an s-control or custom development.  I feel like this should be possible since the opporunity ID is housed there.  Any help is much appreciated.  Thanks!

We have a very complicated round robin that works with different types of assignment numbers.  We have a few types of leads that we'd like to prevent from ever getting an assignment number.  Since validation rules are the only thing to fire before assignment rules, is there a way to based if the auto number fields are populated by other field information in the lead record when it's created? Or will the auto number field populate regardless?

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