Governor Limits

Governor limits are the apex run time limits enforced by the apex run time engine. If you write non-optimized code, your application will get slow and you will see performance issues down the line. But if you write very bad code, salesforce ensures that you will not be using the resource from other applications imposing the governor limit.

Why this is useful: As Apex runs on the shared and multi-tenant environment (Where multiple resources can use the single application at a time), governor limits ensure that code does not monopolize the resource, and each and every user can use the system with no unexpected error.

What happens when code exceeds the limit: If your code exceeds a limit, the associated governor throws the exception error and terminates the request. 

How to take care of governor limits: While writing the code, we must take care of the governor limits and should write the optimized code and should use the best practice of apex. Like avoiding the Too Many SOQL queries, we must ensure the query is not within the “for loop” or particular trigger is not getting fired multiple times. Also if you have a large number of data, we can use the asynchronous class (Batch class)

Important Governor limits:

No of SOQL Query: 100

No of query rows: 50K

No of SOSL: 20

No of DML: 150

No of DML rows:  10K

Maximum Heap Size: 6 MB

Number of future calls: 50

ANT Tool

Prerequisites for Using the Force.com Migration Tool

1.  JAVA (JDK latest version)  use java -version in cmd to know the version of java in your machine                             
2. ANT (latest version) Use Ant -version in the command prompt to know the version of ANT in you machine 
3. Migration Tool (Download latest version from the Salesforce)

Follow the below steps for using Migration Tool:

Step 1: Create the below User Variables
If you have admin right:
Create the below User Variables (Right Click My Computer -> Properties -> Advanced System Settings - > Environment Variables - > User Variables)
If you do not have admin right:
Then Control Panel -> User Accounts-> User Accounts -> Environment Variables - > User Variables

• JAVA_HOME = <path where jdk is installed in your computer>         
• Example - C:\Program Files\Java\jdk1.8.0_25   
• ANT_HOME = <path where ant is installed in your computer>
•   Example C:\Program Files (x86)\apache-ant-1.9.4
• PATH = <path where jdk bin is installed in your computer>; <path where ant is installed in your computer>
• Example  C:\Program Files\Java\jdk1.8.0_25 \bin;C:\Program Files (x86)\apache-ant-1.9.4/bin

Step 2: Setup SFDC Migration tool

1. Extract the Migration Tool Zip file in your local directory, available in Salesforce at :Setup-> Tools ->Force.com Migration Tool
2. Copy the "ant-salesforce" jar file from the extracted folder and paste within lib folder where Ant is installed.
3. Open the Build.properties file from the Migration Tool folder. In the build.properties, update the credentials:
4. Put your package.xml in the folder Migration Tool - > unpackage
5. Retrieve the meta data from the Source org using the below command – Please note the credentials given in build.properties are of source org.  
   ant retrieveUnpackaged 
6. Change the credentials in build.properties and update with the Target org and run the deploy command for the validation as below:ant deployUnpackaged

Issue Faced:

Proxy Setting Issue

Proxy issue can be resolved by configure in the build.xml file as below:

     <target name="proxy">

 <property name="proxy.host" value="*.**.***.*" />

 <property name="proxy.port" value="**"/>

<property name="proxy.user" value=""/>

<property name="proxy.pwd" value=""/>

<setproxy proxyhost="${proxy.host}" proxyport="${proxy.port}" proxyuser="${proxy.user}" proxypassword="${proxy.pwd}" /></target>

Also use depends="proxy" in the target tag as below:

<target name="retrieveUnpackaged" depends="proxy">

      <!--<mkdir dir="retrieveUnpackaged"/>-->

      <!-- Retrieve the contents into another directory -->

 <sf:retrieve username="${sf.username}" password="${sf.password}" serverurl="${sf.serverurl}" maxPoll="${sf.maxPoll}" retrieveTarget="RetriveFromOGTestForbug" unpackaged="RetriveFromOGTestForbug/package.xml"/> </target>

Heap Size Issue:

If migration code is very large then we can get Heap size issue. I have faced this issue and we have resolved it as below:

1. Go to ANT directory (Where ANT is installed) for example: in C drive as below:                   C:\apache-ant-1.9.4-bin\apache-ant-1.9.4\bin
2. Open ANT batch file in notepade++                                                                                            Set ANT_OPTS =-Xmx2048m                                                                                    JAVA_OPTS = - Xmx2048m in the setDefaultAntHome as below:
   

Version Control

• Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.

• The code programmers write changes often. Bugs need to be fixed, features need to be added, and content needs to be changed. Most code is stored as plain old text files, and the code is changed by editing these files. Every time a change is saved, the old version of the file is overwritten with a new one. Unfortunately, no programmer is perfect, and sometimes, mistakes are made. If you make a change to a file, save it, compile it, and find out that something went wrong, it's often helpful to be able to go back to the old version or to get a report of what was actually changed, in order to focus on what may have gone wrong.

Types of Version Control

There are many version control systems out there. Often they are divided into two groups: “centralized” and “distributed”.

Centralized Version Control

• Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

• “Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.

• Most modern version control systems deal with “changesets,” which simply are groups of changes (possibly too many files) that should be treated as a cohesive whole. For example, a change to a C header file and the corresponding .c file should always be kept together.

• Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly. Some of the most common centralized version control systems you may have heard of or used are CVS, Subversion (or SVN), and Perforce.

Distributed Version Control

• In the past five years or so a new breed of tools has appeared: so-called “distributed” version control systems (DVCS for short). The three most popular of these are Mercurial, Git, and Bazaar.

• These systems do not necessarily rely on a central server to store all the versions of a project’s files. Instead, every developer “clones” a copy of a repository and has the full history of the project on their own hard drive. This copy (or “clone”) has all of the metadata of the original.

• This method may sound wasteful, but in practice, it’s not a problem. Most programming projects consist mostly of plain text files (and maybe a few images), and disk space is so cheap that storing many copies of a file doesn’t create a noticeable dent in a hard drive’s free space. Modern systems also compress the files to use even less space.

• The act of getting new changes from a repository is usually called “pulling,” and the act of moving your own changes to a repository is called “pushing”. In both cases, you move changesets (changes to files groups as coherent wholes), not single-file diffs.

• One common misconception about distributed version control systems is that there cannot be a central project repository. This is simply not true – there is nothing stopping you from saying “this copy of the project is the authoritative one.” This means that instead of a central repository being required by the tools you use, it is now optional and purely a social issue.

Git Is a Version Control Application

Git is the application that keeps track of everything related to the changes in your project over time. Git is an open-source program for tracking changes in text files. Let’s start by defining a few key terms:

Repository

• It refers to a storage location, often for safety or preservation. A repository contains all of the project files (including documentation), and stores each file's revision history. Repositories can have multiple collaborators and can be either public or private.

• A repository is the most basic element of GitHub. It’s easiest to imagine it as a project folder. However, unlike an ordinary folder on your laptop, a GitHub repository also offers simple and powerful tools for collaborating with others.

• A repository contains all of the files associated with a project (including documentation), and stores each file’s revision history.

Commit

• A commit, or "revision", is an individual change to a file (or set of files).

• It's like when you save a file, except with Git, every time you save it creates a unique ID (a.k.a. the "SHA" or "hash") that allows you to keep a record of what changes were made when and by who. Commits usually contain a commit message which is a brief description of what changes were made.

Fork

• A fork is a personal copy of another user's repository that lives on your account.

• Forks allow you to freely make changes to a project without affecting the original. Forks remain attached to the original, allowing you to submit a pull request to the original author to update with your changes.

Clone

• A clone is a copy of a repository that lives on your computer instead of on a website's server somewhere, or the act of making that copy.

• With your clone, you can edit the files in your preferred editor and use Git to keep track of your changes without having to be online.

Push

• Pushing refers to sending your committed changes to a remote repository such as Bitbucket. For instance, if you change something locally, you'd want to then push those changes so that others may access them.

Pull requests

• Pull requests let you tell others about changes you've pushed to a Bitbucket repository. Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.

Fetch

• Fetching refers to getting the latest changes from an online repository (like Bitbucket) without merging them in. Once these changes are fetched you can compare them to your local branches (the code residing on your local machine)

 Working on GitHub Versus Working Locally

• You can make changes to your project directly on GitHub, but most people prefer to work on their local machine so they can make changes in their favorite IDE or text editor. Let’s review a couple important terms:

• The remote repository is a copy of the repository on GitHub. All collaborators synchronize their changes with this, making it the source of truth for the group.

• Local repositories are git repositories stored on a user's computer. If the local directory is linked to a remote repository, then the local repository is a full copy with everything on the remote repository, including all of its files, branches, and history.

The local and remote repositories only interact when you run one of the four network commands in Git: git clone, git fetch, git pull, and git push.

 

Using Git / Basic commands

Git uses a small number of commands to perform its basic operations.

 

 

Overview of the GitHub Workflow

The main steps are:

1. Create a branch off of the master

2. Make commits

3. Open a pull request

4. Collaborate

5. Make more commits

6. Discuss and review code with team members

7. Deploy for final testing

8. Merge your branch into the master branch