You need to sign in to do that
Don't have an account?

How to achieve the salesforce CI?
Can any one please suggest me how to achieve the Salesforce CI to retrieve the metadata from one org and deploy into another org.
You need to sign in to do that
Don't have an account?
https://developer.salesforce.com/page/Continuous_Integration_How-To
https://developer.salesforce.com/blogs/developer-relations/2013/03/setting-up-jenkins-for-force-com-continuous-integration.html
there are quite a few different ways of doing this. At a basic level you can extract all metadata through the metadata API (using the ant based force.com migration tool (https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_deploying_ant.htm" target="_blank)). This will allow you to extract the metadata as files, and package them up and deploy them to another org.
There are of course many tools out there that abstract this process and provide more of a streamlined interface. For example I would highl recommend the app exchange tool called Copado (https://appexchange.salesforce.com/listingDetail?listingId=a0N3000000B3dgGEAR" target="_blank). Under the hood it uses the force.com migration tool, but it's point and click (as in you select a source org and the meta data you want, and the target org you want to deploy to). You can tyr it for free, and then decide to pay if you like it.
There are other methods of coure, you can setup a Jenkins CI server, and manually build your ant scripts to do proper CI (continual deployment to a QA sandbox for example). I would recommend readin gthis artilce on Setting Up Jenkins for Force.com Continuous Integration (https://developer.salesforce.com/blogs/developer-relations/2013/03/setting-up-jenkins-for-force-com-continuous-integration.html" target="_blank).
Good Luck!!
EX:
1>Setup --> Permission Sets --> navigate to one of the 'Permission Set Label' --> Object Settings --> click on Tasks --> click on Edit button --> navigate to one of the field --> enable the both (Read & Edit ) checkboxes --> then Save
2>setup->object->task->find paglayout section ->find "given Task - Click Submitted" ->click on edit ->drag and drop cancel button->save.
Could you please suggest me how to automate this type of Post Deployment Steps in SalesForce. Because I am getting 100's of Post Deployment Steps. These are one of the Post Deployment Steps.
Steps you have mentioned - You can do settings like permission set, page layouts in one org and deploy with the help of force.com IDE or any other tool.
You can create post deployment checklists to finalize the configuration of your target environment after the configuration and development components are deployed.
1) Through Meta-Data
Even if it is a post deployment step - you can still use the meta data to push in an entirely new Permission set (with those permissions set). For that there is a section in the XML called object permissions where you can set this (https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_permissionset.htm#permissionSetObjectPermissions_title). For the second one, that is just a layout meta data that you copy to the traget. Almost every config in salesforce you can set through meta-data - I would read up on pushing config through using meta-data. If it's a post-deployment step, just make it a secondary step in Jenkins
2) Use an uatomation tool
I have seen some of these tasks done by using Selenium (https://www.topcoder.com/blog/automate-salesforce-administrative-tasks-with-selenium/) to act like a user loggin in and making these changes. I would advise against this though as you can run into a lot of problems.
Generally I would recommend looking at a tool like Copado - it is fantastic for these types of steps, and it even has some additional features (like running anonymous Apex as a step, transferring data, copying custom setting values, etc.)
The one work around I can think of is to create an Integration profile by cloning Sys Admin. Then deploy and run as that profile. But that has some issues. You have to make sure to pull the profile and ever object in the same package so that the profile is complete. In the source org, you'll need to make sure you keep that profile updated as new items are added. And that still doesn't solve the problem that the System Administrator profile will be useless in the target org (unless you do a bunch of manual clicking to grant access).
Anyone else have any other ideas on dealing with lack of permissions for the System Administrator profile when doing continuous integration?