You need to sign in to do that
Don't have an account?
Packaging and deployment woes
Hello all:
So my question concerns a complicated situation. I'm new enough to packaging that I'm not at all sure I'm going to state the problem accurately but I'll try.
I'm part of a team working on a Force.com app. The org in which we're working has a development sandbox, a test/QA environment, and a production environment. We're using the Force.com Eclipse IDE for pretty much everything, including migration from dev to test.
A few weeks ago we tried to push to production. We encountered an error that prevented our tests from running, and we're following up on that issue with SFDC so that's a separate converstion.
Here's the nub. To get our app deployed it was recommended we instead upload our package to production via the web interface. This seems to have worked, net the usual tinkering. We uploaded as an unmanaged package.(Side note: am I right in thinking this involved somehow funneling the app through the AppExchange?)
The problem is that now we can no longer deploy using our original package, the one recognized by the IDE and the one we use to keep our project definition together. What we've now been told by those who specialize in deployment in this org is that we can only deploy to production using Ant, and sending the deployer a listof all the changed components so that an Ant script can be pulled together that just updates those components.
I can tell there are things I still just don't "get" about packages and migration, and I know the above is a lot to wade through, but I'm curious whether any can tell me what was different about uploading the package via the web UI, and why our Eclipse IDE deployments apparently no longer work.
Any insight greatfully received.
-- Steve Lane
First off, merely uploading a package doesn't make it available on the AppExchange. After you upload a package, you can optionally register it on the AppExchange, but that's a separate step. If you don't register it on the AppExchange, then the package is still installable via the installation URL that you see after upload (or when you click on the version link in your development organization).
The eclipse IDE plug-in (and the similar ant tasks) are written on top of our metadata API. Essentially the retrieve extracts metadata from your organization into a set of XML files. The deploy operation does the reverse and creates/updates metadata in your organization from the XML files.
Typically you'd use the eclipse plug-in / ant tasks when you're moving metadata between different organizations (or source control) within the same company. For instance when multiple developers in separate salesforce organizations are collaborating on a project.
Packaging is more intended for ISVs developing applications for their customers to install.
That being said, unmanaged packages blur the lines since they pre-date the metadata API and are often used for moving metadata within the same company.
Hope that helps. Can you give some more details on the error you're seeing using the eclipse IDE?
Thanks. The more I learn about packaging, the more it seems a poor fit for what we need to do. We're developing in a large, complex org. We have two sandboxes, one for development and one for testing, and of course we have production.
Initially we used what I'll call a "development" package (is there a better name for this?) solely as a means to define our Eclipse project. New developers setting up the project just pull all components from package X.
When we tried to deploy to production we ran into an issue (escalated to SFDC already) wherein the code base was so large that the "run all tests" task timed out on the client side. It was advised we deploy via an unmanaged package to get around this, which we did.
The unmanaged package appears not to be updatable. If we try to add a field to a custom object in the package, then redeploy that custom object via Eclipse, we get the message that we can't update an installed package. Oddly, deploying just the one added field via Ant did work.
My instinct is we should ditch packaging as a project definition tool. It seems easiest to keep the project checked into source control and have the repository be the project definition.
Still puzzled why Eclipse can't update items in our installed package and it seems Ant can.
I have problem regarding Package deployment in sales-force :( Its very strange that I have just 4 triggers and have not any single Apex Class so what I have to do for deployment I need TEST Methods for my Triggers. I created test methods for my all four triggers when I am going to upload option of package I am getting following ERROR :(
Component
ProblemApex Class Average test coverage across all Apex Classes and Triggers is 1%, at least 75% test coverage is required
Thats very strange because I have not Apex class even that I am getting this problem please help me in this problem :(
My Triggers are mentioned below:
Trigger 1:
Trigger 2:
Trigger 3:
Trigger 4:
Please see reply for test class I did n reply because of character limit :(
Regards,
Asif Khan
Now I created these test Cases against above mentioned Triggers :(
But on uploading of package I am getting this error
Average test coverage across all Apex Classes and Triggers is 1%, at least 75% test coverage is required
Please help me in this
Thanks,
Asif Khan