3

When running a deployment via a change set or via the API (using ANT or Eclipse) with the "check-only" parameter set to true, will any users or data in the org I'm deploying to feel the effect of the deployment (even momentarily?)

I would find it very odd if this were the case, but if I read the documentation on deployment to production orgs very carefully (found here: http://www.salesforce.com/us/developer/docs/dev_lifecycle/Content/deploy.htm), I could get the feeling that something might be fishy? The documentation mentions the option of doing a "check-only" deployment after having stressed that users should be locked out while running actual deployments.

Improve this question

1 Answer 1

Reset to default
2

I believe the only users that should be impacted would be users with the Customize Application permission who continue to make modifications to your org's configuration during the deployment validation process (such as modifying a validation rule or updating a sharing setting). They should get a message that the org is locked and be unable to save their changes, which is more of a disruption in their access than anything that could impact the results of the validation. However, it is possible that a user could be in the middle of some long-running process (such as running test cases or updating sharing settings) that could prevent the validation from even starting in the first place.

Also, if your test cases rely on certain data being present and in a particular configuration (rather than mocking up the data as part of the test case, which is a best practice), allowing users to make changes to data in the org during the validation window could potentially impact the success of your test cases. Of course, this is easily preventable by writing test cases that create their own data or ensuring that they utilize the @IsTest(SeeAllData=false) annotation introduced in API version 24.0.

Other than that, your end-users really should not be impacted by a validation-only deployment, as all changes introduced are never actually committed and will be rolled back following the completion of all tests. In my experience, locking out all users should only be necessary during the actual deployment window (especially when manual configuration changes are necessary in addition to the automated deployment and it would be undesirable/dangerous for a user to be accessing the system prior to the completion of the manual changes).

Improve this answer
6
  • Good points. This is also how I expect things to work. The reason for this question is that after running deployment validations against production, we've experienced some extremely weird data situations in the prod org (opportunities with a closed StageName, but the isClosed=false). This might be unrelated, but we're thinking broad here. Obviously we're also awaiting input from SFDC support on this one.
    – sorenkrabbe
    Sep 11, 2012 at 13:03
  • What were Last Modified Date and Last Modified By showing in those cases?
    – JCD
    Sep 11, 2012 at 17:29
  • Nothing too interesting. User was the user who worked with the oppt, and modified date was when he made the update to close the oppt.
    – sorenkrabbe
    Sep 12, 2012 at 11:52
  • So it was closed with IsClosed set to true, then after the deployment validation it was in the same stage but with IsClosed set to false? This sounds like an issue for SFDC support.
    – JCD
    Sep 12, 2012 at 12:26
  • Right... except I don't know (and seriously hope) that there is no connection between the odd data and the deployment verifications.
    – sorenkrabbe
    Sep 13, 2012 at 12:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .