Agile is an approach to software development that emphasizes incremental delivery, team collaboration and continual learning.

Instead of delivering everything at the end of a development project, agile teams focus on creating minimum viable products (MVPs) that are improved on through several iterations. Development teams request and implement feedback after each iteration or ‘sprint’. 

Learn more at:
​https://en.wikipedia.org/wiki/Agile_software_development
​

Amazon Elastic Compute Cloud (EC2) provides scalable computing capacity in the Amazon Web Services (AWS) cloud. It eliminates the need to invest in hardware up front, so you can develop and deploy applications faster. You can use Amazon EC2 to launch as many or as few virtual servers as you need, configure security and networking, and manage storage. Amazon EC2 lets you scale up or down to handle changes in requirements or spikes in popularity, reducing your need to forecast traffic.

At Gearset, we use EC2 to run the Gearset app. It gives us the ability to scale the app as demand increases to make sure it's running smoothly for everyone.

Learn more at: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html
​

Amazon Elastic File Service (EFS) provides a scalable, elastic file system for Linux-based workloads for use with AWS Cloud services and on-premise resources.

Gearset uses EFS as a storage location for data.

Learn more at:
​https://aws.amazon.com/efs/
​

Amazon Simple Storage Solution (S3) is storage for the internet. It’s designed to make web-scale computing easier for developers. S3’s simple web services interface can be used to store and retrieve any amount of data, at any time, from anywhere on the web. It gives any developer access to the same highly scalable, reliable, fast, inexpensive data storage infrastructure that Amazon uses to run its own global network of websites. The service aims to maximize the benefits of scale and to pass those benefits on to developers.

Gearset uses S3 as a storage location for data.

Learn more at:
​https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html
​

Amazon Web Services (AWS) is the leading cloud hosting provider and has dozens of data centers located around the world. Many of the world's largest companies rely on AWS to run their software, including Salesforce.

Gearset uses AWS as its hosting and datacenter provider.

Learn more at:
​https://aws.amazon.com/what-is-aws/
​

The Ant migration tool (also known as the Force.com migration tool) is a free tool provided by Salesforce. It’s a Java/Ant-based command-line utility for moving metadata between a local folder and an org.

As a command-line tool, all interactions with Ant are managed via the command line interface (CLI) - there’s no user interface.

Ant allows users to deploy sets of metadata changes from one environment to another by building code packages manually. Packages are built by the developer and organized into a single folder, which is then deployed using the tool.

Ant also makes use of a package file that indexes the changes included in the deployment.

Learn more at:
​https://developer.salesforce.com/docs/atlas.en-us.daas.meta/daas/meta_development.htm
​

Apex is a programming language designed to let you add and interact with data in Salesforce. It gives developers more flexibility in their customization of the Salesforce platform.

Apex allows developers to create custom functions and logic, extending the core functions provided by Salesforce, and to build custom applications to meet the needs of their business.

Learn more at:
​https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm
​

An application programming interface (API) allows two pieces of software to talk to each other and share information. For example, Gearset uses the Metadata API (MDAPI) to download metadata from Salesforce.

Learn more at:
​https://www.mulesoft.com/resources/api/what-is-an-api
​

Application lifecycle management (ALM) is the process of designing, developing, testing and deploying a software application. ALM covers the entire lifecycle from conception, through to ongoing improvement, support and ultimately the application’s retirement.

Learn more at:
​https://en.wikipedia.org/wiki/Application_lifecycle_management
​

Azure is a cloud hosting platform run by Microsoft that competes with AWS. Although there are some differences between Azure and AWS, they're generally competing in the same markets for the same customers. AWS is generally seen as the market leader, but Azure is another popular choice.

Learn more at:
​https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/get-started/what-is-azure
​

In source control, branches provide independent working environments for developers where new features can be built and tested in isolation from other development work.

Branches are part of the everyday development process and allow developers to work in parallel, review each other’s work, and control when changes are released for testing.

Learn more at:
​https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell
​

Within the Gearset app, change monitoring allows you to monitor changes being made across your Salesforce environments with automatic org snapshots, detailed change tracking, and rapid deployment and rollback.

Learn more at:
​https://gearset.com/product/metadata-monitoring
​

Change sets is one of the tools provided by Salesforce for migrating metadata changes between orgs. It provides a way of synchronizing the metadata between a source org and a target org.

Change sets is supported by Enterprise and Unlimited Edition environments. It's a point-and-click tool which does not require installation of specific software or the downloading and uploading of files. This tool is available via the Salesforce UI.

Two orgs are configured so that they can send and receive changes between each other. These orgs must first be linked via a relationship to a shared production instance - for example, a sandbox and a developer environment, both created from the same production org.

Change sets are built by selecting components manually, via the UI in the source org. Once the change set has been built, it’s deployed to and staged in the target org, where the changes can then be accepted and applied. The two orgs will then have the same specific metadata described by the change set, and the deployment is complete.

Learn more at:
​https://docs.gearset.com/en/articles/2285864-change-sets
​

Chatter is a collaboration tool used on the Salesforce platform. Different Chatter features - used for collaboration on all sorts of company projects, sales opportunities and marketing campaigns - can be incorporated into Salesforce orgs. Some companies also use Chatter as an employee directory. Chatter users can manage their information feeds and control how they receive notifications.  

Learn more at
​https://www.salesforce.com/products/chatter/features/
​

A command line interface (CLI) is a text-based tool used to view and manage computer files. To use Ant or SFDX to deploy changes to orgs, you need to use a CLI.

As CLIs are not user-friendly and require technical knowledge, they are only used by Salesforce developers and experienced users. Tools like Gearset are built on top of CLIs, but provide an easy-to-use interface which doesn’t require coding knowledge to operate.

Learn more at:
​https://www.techopedia.com/definition/3337/command-line-interface-cli
​

In source control, commits are collections of changes which a developer adds to a branch, recording the latest stage in their development progress.

As a developer works, the version control system automatically tracks the changes they make to files. When a portion of the feature is complete, the developer ‘commits’ these changes, and gives an informative description of the changes made.

Learn more at:
​https://www.atlassian.com/git/tutorials/saving-changes/git-commit
​

Continuous delivery (CD) is an extension of continuous integration (CI). It makes sure that you can release new changes to your customers quickly and reliably. In addition to automated testing (CI), you can use CD to automate your release process. CD means having the ability to deploy your application at any time, at the click of a button.

In theory, CD means you can decide to release daily, weekly, fortnightly, or whatever suits your business requirements. But to get the real benefits of CD, you should deploy to production often enough to make sure that you release small batches that are easy to troubleshoot if there’s a problem.

In the Salesforce world, teams often use “CI” and “CD” interchangeably, although CI is the more prevalent term.

Learn more at:
​https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment
​

Continuous integration (CI) is the process of automating the build and testing of code every time a team member commits changes to version control. CI encourages developers to share their code and unit tests by merging their changes into a shared version control repository after each small task. Code commits trigger an automated build system to grab the latest code from the shared repository and to build, test, and validate the full master branch (also known as the ‘trunk’ or ‘main’).

CI emerged as a best practice because software developers often work in isolation, and then need to integrate their changes with the rest of the team’s code base. Waiting days or weeks to integrate new code can result in merge conflicts, hard-to-fix bugs, diverging code strategies, and duplicated efforts. To avoid these problems, CI requires that the development team’s code be continuously merged to a shared version control branch.

Learn more at:
​https://docs.microsoft.com/en-us/azure/devops/learn/what-is-continuous-integration
​

Many sales organizations face a common problem: producing accurate and professional sales quotes for prospects quickly, while eliminating errors and inefficiencies. Configure Price Quote (CPQ) is a growing software category that tackles this challenge head-on.

CPQ allows sales teams to quickly generate quotes for products through the Salesforce UI, and send them out to customers. CPQ consists of both metadata and data.

Learn more at:
​https://www.salesforce.com/products/cpq/resources/what-is-salesforce-cpq/
​

In Salesforce, objects function a bit like tables in a database. They’re essentially containers for data. Objects have fields, which are a bit like the rows of the table. For example, the Account object stores all the information about your customer accounts. On that object are fields for Account Manager, Account Revenue and Main Contact, etc. 

There are two main types of object: standard objects and custom objects. Custom objects are created by teams, to store the kinds of information that are unique and important to their business. Custom objects can be modified and even deleted.

Learn more at: https://trailhead.salesforce.com/en/content/learn/modules/data_modeling/objects_intro
​

The business information stored inside the Salesforce org is the data. When you add a customer’s contact information into the Account object, you’re adding data. Each item of data is known as a record.

As a rough analogy, think of a spreadsheet. You have column names, and you have the rows in the table. The names and email addresses in the rows of the spreadsheet are the data. Your data is highly sensitive, as it includes your business information and your customers’ personal details.

Learn more at:
​https://docs.gearset.com/en/articles/2285671-metadata-versus-data
​

Salesforce has a motto of "clicks not code" when it comes to development on the platform. This encourages users to minimize code use and instead make changes through the platform’s UI.

These kinds of changes are known as declarative changes, and they form the mainstay of many users' customization of their orgs.

Some customizations require more complexity than can be achieved via declarative changes. They may require writing custom logic which triggers complex workflows, or custom integrations to perform automated tasks outside of Salesforce.

Changes of this second sort are generally known as code changes, as they require the Salesforce developer to write new code rather than make changes by clicking in the UI.

Learn more at:
​https://docs.gearset.com/en/articles/2285697-declarative-changes
​

Deployment within Salesforce means transferring metadata and/or data from one Salesforce org to another, including scratch orgs, or it could be to/from source control or local repos. Various deployment tools can be used, including change sets, the Ant migration tool, SFDX packages and third-party tools such as Gearset.

Learn more at:
​https://gearset.com/product/deployments
​

Developer orgs are created in Salesforce with a Developer Edition account. They include access to the Lightning platform and APIs, and are ideal for building new, discrete features for the Salesforce platform. Apex can be written in developer orgs (unlike in production orgs).
​
​Learn more at:
​https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_get_dev_account.htm
​

Salesforce DX introduced a number of new tools, including the Developer Hub (Dev Hub), which lets you create and manage scratch orgs.

Almost any org can be converted into a Dev Hub by changing the settings.

Learn more at:
​https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/dev_hub_intro.htm
​

DevOps is the practice that aims to combine software development and operations, which have traditionally been kept separate. DevOps refers to the technical, operational aspects of releasing software - packaging, releasing and monitoring changes through the software development lifecycle.

DevOps suggests that responsibility for packaging, releasing and monitoring is shared across the whole development team. It also implies a heavy reliance on automation, allowing teams to release regularly and reliably, with much shorter release cycles as a result.

Learn more at:
​https://gearset.com/resources#whitepaper-sfdx
​

The Git version control system stores and transmits data in the form of differences (diffs or deltas) between files. The Gearset comparison engine uses a semantic diff that takes into account the underlying meaning of the metadata. This means it can show the cause and effect of changes rather than just the differences between files, including the relationships and dependencies between objects. 

Learn more at:
​https://en.wikipedia.org/wiki/Delta_encoding
​

FastSpring is a leading e-commerce payment service provider. Gearset resells through FastSpring to make it easier for customers to purchase our software in the US and around the world. FastSpring is fully PCI-DSS compliant and ensures your payment details are handled with the utmost security.

The main reason we use FastSpring is to help us calculate different tax rates when selling Gearset around the world. As a subscription service, the rules for collecting and reporting tax is different in each US state, and in different countries. FastSpring handles all of this for us.

Learn more at:
​https://fastspring.com/
​

There are several different types of VCS (version control system), but by far the most commonly used is Git.

Git is the underlying framework that defines how changes to files are tracked, and how users can interact with the VCS. Git is known as a distributed version control system because a full copy of the repository - all of the project's files - is distributed to each developer. It was designed for coordinating work among programmers, but it can be used to track changes in any set of files.

Git providers such as GitHub, Bitbucket and GitLab all build on the base Git framework to provide their version control systems.

Note: version control may also be referred to as source control.

Learn more at:
​https://www.atlassian.com/git/tutorials/what-is-git
​

A hotfix is code that is developed and released into production as quickly as possible in order to correct a bug in a current software release. 

Learn more at:
​https://en.wikipedia.org/wiki/Hotfix
​

An integrated development environment (IDE) provides developers with a comprehensive set of software development tools. An IDE normally consists of a source code editor, build automation tools, and a debugger.

Essentially, an IDE is a fancy text editor that helps devs to write code. In the Salesforce world, Visual Studio Code is one of the most popular IDEs.

Learn more at:
​https://en.wikipedia.org/wiki/Integrated_development_environment
​

Integration testing is run against multiple individual software changes as a group. Changes and fixes from multiple development environments must pass through integration testing before they’re promoted to the production organization. Typically, integration testing is performed after unit tests are run by developers on their individual work items and after acceptance tests have been executed on the build.

Learn more at:
​https://en.wikipedia.org/wiki/Integration_testing
​

JSON (JavaScript Object Notation) is a format that’s used to exchange data. It’s easy for humans to read and for machines to parse and generate. 

Learn more at:
​https://www.json.org/
​

Lightning Experience is the latest Salesforce desktop UI, which is available alongside the older Salesforce Classic. As the name suggests, Lightning was designed to be faster - mainly by being more customizable for each user. Lightning also gives users access to additional features, such as the Einstein Analytics reporting tools and Lightning components. Users can switch to viewing their environment in Salesforce Classic, but lose the functionality that comes with Lightning if they do so.

Learn more at: https://trailhead.salesforce.com/en/content/learn/modules/lex_migration_introduction/lex_migration_introduction_whatis
​

Lightning Web Components (LWC) is a web framework for building web apps both on and off the Salesforce platform. It’s a new breed of lightweight frameworks built on web standards, with custom elements, templates, shadow DOM, decorators, modules, and other new language constructs available in ECMAScript 7 and beyond.

Learn more at:
​https://developer.salesforce.com/blogs/2018/12/introducing-lightning-web-components.html
​

In Salesforce, a package is simply a way of logically organizing chunks of metadata together, similar to putting files into a folder on your computer. This helps developers track related features more easily. Packages can be either managed or unmanaged.

Managed packages are distributed via the Salesforce AppExchange and offer custom functionality on the Salesforce platform. Developers of these packages prevent their work being copied by locking access to the underlying code through a managed package. End users can install managed packages, but they can't see the contents or edit them. The packages continue to be ‘managed’ by the developers, who may release updates. Managed packages also exist in their own unique namespaces, which are essentially unique folder names.

Learn more at:
​https://help.salesforce.com/articleView?id=managing_packages.htm&type=5
​

In source control, merging is the process of integrating changes from one branch to another, including into master.

Merging is typically done when a feature is ready for user testing in Salesforce orgs, and usually involves code review by other members of the development team. During a merge, the source control system will automatically splice together the two versions of the files to produce a coherent end result using advanced merging algorithms. Sometimes this can't be done, resulting in a merge conflict. Merge conflicts must be resolved manually by a member of the development team.

Learn more at:
​https://www.atlassian.com/git/tutorials/using-branches/git-merge
​

The structure of a Salesforce org is encoded in its metadata. When you make changes, such as adding a new custom field, you’re actually altering the metadata. Things like user access to pages, color schemes, and UI layouts are all controlled by metadata.

As a rough analogy, think of a spreadsheet. You have column names and you have the rows in the table. The column names (e.g. “Name”), the cell borders, and the color of the headers are metadata.

Learn more at:
​https://docs.gearset.com/en/articles/2285671-metadata-versus-data
​

The Salesforce Metadata API (MDAPI) is the API Gearset uses to download and deploy changes to users’ orgs. When you run a comparison in Gearset, metadata gets requested via the MDAPI. When you run a deployment to an org in Gearset, that’s also being done over the MDAPI.

The MDAPI supports the majority of Salesforce metadata types, but there are some exceptions. These are known as ‘Unsupported Metadata’ types in Salesforce.

Learn more at:
​https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_intro.htm
​

OAuth 2.0 is an industry-standard form of authorization that unrelated apps, APIs and servers can use to provide users with secure access. OAuth works over HTTPS and authorizes a user’s device by means of access tokens rather than user credentials, which means the end service doesn’t see your actual password. The underlying technology is described as third-party, user-agent, delegated authorization.

When you log into Gearset using your Salesforce, Google, or LinkedIn account, you’re using OAuth.

Learn more at:
​https://en.wikipedia.org/wiki/OAuth
​

When a customer purchases Salesforce, they’re provided with an instance of Salesforce called an organization, or org for short. This org holds all of their data and applications. It is separate from all other orgs and can only be accessed by licensed users. Each company can customize the structure and appearance of their org, according to their requirements.

Various types of org are used for different purposes. The production org (sometimes referred to as ‘prod’) is the org that is actively being used to run your business. Sandboxes are used for testing features and getting feedback from users. Developer orgs are used to build and test new features and customizations, which are then released into a sandbox or production. Scratch orgs are short-lived environments that you can quickly spin up and use as a clean sandbox for testing.
​
​Learn more at:
​https://docs.gearset.com/en/articles/2285301-salesforce-organizations
​

The package.xml (also referred to as the package file or package manifest) is used when you retrieve or deploy metadata using the Salesforce Ant tool or the SFDX CLI.

Salesforce uses the package file to define the metadata you request from or deploy to an org. It's essentially the table of contents that Salesforce uses to find and provide or apply the list of metadata items.

In Gearset, the package.xml can be used to filter the metadata in your comparison results.

Learn more at:
​https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/manifest_samples.htm

https://docs.gearset.com/en/articles/2704464-filtering-comparison-results-by-package-xml
​

Picklists in Salesforce allow your users to select one value (or more, in the case of multi-select picklists) from a list that you define. Picklists are fields associated with individual objects and are either standard picklists that share a global value set or customized picklists with values that you define for your org.

Learn more at: https://trailhead.salesforce.com/en/content/learn/modules/picklist_admin/picklist_admin_start
​

Programming Mistake Detector (PMD) is an open-source code analyzer that reports on issues found within application code. PMD includes built-in rule sets and supports the ability to write custom rules, and has a custom rule set for Apex. PMD is the framework Gearset uses to run its static code analysis (SCA).

Learn more at:
​https://pmd.github.io/
​

A problem analyzer gets triggered within Gearset when a user attempts to deploy metadata that might cause the deployment to fail. After a user has run a comparison of two orgs, the deployment is checked for potential issues, including: 

This analysis is performed by Gearset, and is not part of the Salesforce package testing.

Learn more at:
​https://docs.gearset.com/en/articles/625488-an-introduction-to-gearset-s-problem-analyzers
​

A production org (often shortened to ‘prod’) is the live instance of your Salesforce environment used by your employees in everyday business operations. There are some limitations to the customizations you can make in production. In particular, Apex can only be run, not written. 

Generally, it is a bad idea to make configuration changes directly in production - any error might bring your entire company’s operation to a standstill. Instead, changes and features should be built and tested in other orgs, before being deployed to production.

Learn more at:
​https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_get_dev_account.htm
​

Both of these settings are used to control user access to parts of your Salesforce org. The profile is the user's base set of permissions, which restricts the access they have - for instance to see or edit certain fields. A permission set also defines access rights and typically extends a user’s profile permissions. 

Every user in a Salesforce org must be assigned a profile, usually according to their role within the company. Permission sets are assigned to individual users as required.

Learn more at:
​https://help.salesforce.com/articleView?id=perm_sets_overview.htm&type=5
​

A pull request (PR) or merge request is a term used in version control systems (also called source control systems). In their simplest form, pull requests are a mechanism for a developer to notify team members that they have completed a feature.

Once their feature branch is ready, the developer files a pull request via their version control system. This lets their teammates know that the code can be reviewed and merged into another branch. Through the PR process, the developers and the source control system automatically merge the two sets of work in the two branches together into a single, cohesive branch.

PRs provide a way for teams to give feedback on code, test that it doesn't have any conflicts, track a history of changes, and control when and where code gets merged.

Learn more at:
​https://help.github.com/en/articles/about-pull-requests
​

A regular expression (regex) is used to define a search pattern that will discover more than one result. 

For example, ? specifies that the preceding character in the regex appears zero or one times. So the regex Lighte?ning would find all instances of Lightning and Lightening (a pretty common misspelling in the Salesforce ecosystem!). In this example, the regex will find only two forms: Lightning and Lightening. But a regex can be used to find several forms - even an infinite number.

Regex can be used to make code much more concise and accurate, as the alternative would be to list all possible search terms.

Learn more at:
​https://en.wikipedia.org/wiki/Regular_expression
​

Regression testing describes the process of testing software after it has been changed, in order to make sure that it performs as it should. Regression testing can include tests of the software's functional and non-functional performance. Functional testing checks that the software behaves as it should, producing the required results. Non-functional testing checks how the software operates, such as its speed or its ability to cope with high volumes of data.

Learn more at:
​https://en.wikipedia.org/wiki/Regression_testing
​

Within DevOps, each version of software made public is known as a release. The process of planning, scheduling, building, trialing, releasing, and then monitoring each release is known as release management. 

Release management helps to make sure business needs are met and supported by the ongoing development of software. Many companies have a release manager who has overall oversight of their DevOps team.

Learn more at:
​https://en.wikipedia.org/wiki/Release_management
​

Repositories are central project directories used to store files and track changes to code within a version control system. Repositories, also referred to as ‘repos’, provide a way for teams to share changes, review each other's work, and resolve conflicts. Repositories are based on a central master store of files, with a number of branches containing new features in development.

Learn more at:
​https://docs.github.com/en/get-started/learning-about-github/github-glossary#repository
​

Salesforce (SF), also referred to as salesforce.com (SFDC), started as a Customer Relationship Management (CRM) software, and has expanded to become the largest cloud-hosted CRM. You can run your sales team, support team, company finances, payroll, call centers, and pretty much every part of your business on Salesforce.

Learn more at:
​https://www.salesforce.com/products/what-is-salesforce/
​

Sandbox orgs are copies of your production org on the Salesforce platform that are used to try out and test changes before they go live. Sandboxes are created by cloning a production org, but without some maintenance they can quickly become out-of-sync and need refreshing.

Learn more at:
​https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_get_dev_account.htm
​

Scratch orgs are short-lived Salesforce orgs that were introduced as part of SFDX for building or testing features in a new, temporary environment. Scratch orgs can be created in a few seconds. There are a number of options when spinning up a scratch org, including how many days it will exist before automatic deletion. You can create and deploy changes to and from scratch orgs from within Gearset.

Learn more at:
​https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs.htm%20%20Source%20code
​

The Salesforce Developer Experience (SFDX), also referred to as Salesforce DX, is an initiative launched by Salesforce to provide modern development tools for developers working on the platform. The SFDX tools include:

Learn more at:
​https://docs.gearset.com/en/articles/2290598-an-overview-of-salesforce-dx
​

Software as a Service (SaaS) is a software licensing model where users pay for a regular subscription to a centrally-hosted product. Salesforce and Gearset are both SaaS products.

The main difference between SaaS and locally hosted software is that you don't need to download or install anything with SaaS; it's generally accessed via a web browser. For example, to use Gearset, you just go to app.gearset.com. You don't need to download and install any programs to make it work.

Learn more at:
​https://en.wikipedia.org/wiki/Software_as_a_service
​

Source code can refer to different things depending on the context.

In Salesforce, source code generally refers either to metadata as a general catch-all term, or specifically to the custom code (Apex/Visualforce) that someone has written within Salesforce. The term is most commonly used of code that is being stored in version control (source control).

Learn more at:
​https://en.wikipedia.org/wiki/Source_code
​

In DevOps, the ‘source of truth’ refers to the latest, most complete version of your code. DevOps necessarily means having several versions of your software or product: some versions in which developers are working on new features; and then the version that represents the ‘source of truth’.

Many Salesforce developers treat their live production org as the source of truth. This makes sense, as prod should represent the most up-to-date version of your org. But it is best practice to use a master branch in source control as the source of truth.

Learn more at:
​https://gearset.com/assets/version-control-for-salesforce-whitepaper.pdf
​

Secure (socket) shell (SSH) is a network protocol that gives users - particularly system administrators - a secure way to access a computer over an unsecured network.

At Gearset, we use SSH for some secure connections to our infrastructure and services. The Gearset app also supports SSH connections to Git repositories, which customers can use instead of OAuth.

Learn more at:
​https://searchsecurity.techtarget.com/definition/Secure-Shell

A staging environment is a close copy of your production environment. This is where changes and new features can finally be tested in a production-like environment, to check that they will work as expected when they go live.

Learn more at:
​https://en.wikipedia.org/wiki/Deployment_environment
​

In Salesforce, objects function a bit like tables in a database. They’re essentially containers for data. Objects have fields, which are a bit like the rows of the table. For example, the Account object stores all of the information about your customer accounts. On that object are fields for Account Manager, Account Revenue and Main Contact, etc. 

There are two main types of object: standard objects and custom objects. Standard objects are found in every Salesforce org by default. They include: Account, Contact and Opportunity. Standard objects can be customized, but they cannot be deleted.

Note that in the Salesforce Metadata API, which Gearset uses, standard objects are called custom objects.

Learn more at:
​https://trailhead.salesforce.com/en/content/learn/modules/data_modeling/objects_intro
​

Static code analysis (SCA) reviews your source code (e.g. Apex) to detect common bad practices, catch bugs, and make sure development adheres to coding guidelines. It’s essentially a grammar and style guide for writing code.

SCA helps teams to work more effectively by making it much easier for developers to review and improve each other's code.

Most static code analysis tools define a series of rulesets, identifying different categories of issues that might be detected in your code. These rulesets can then be modified to suit your needs. Gearset automatically runs SCA as part of our manual deployment and CI processes, as well as org monitoring.

SCA is used to check that code is well written and that developers are keeping to the standards set for their team. It's often used alongside unit testing, which checks that the code runs as intended.

Learn more at:
​https://gearset.com/assets/Static-code-analysis-for-apex.pdf
​

A tech stack is a list of all the technologies (programming languages, frameworks and libraries, etc.) and services used to build and run a piece of software.

Learn more at:
​https://stackshare.io/stacks
​

Unit testing is a method for testing software, where individual units of source code can be automatically checked to see if they are fit for purpose. It's generally accepted across all software languages and platforms as a best practice. Developers write unit tests alongside their code.

Unit tests check whether the code you've written works. For instance, if you wrote a bit of code that does X + 5 = Y, you could write a unit test that inputs X = 5 and expects a result of Y = 10. 

Code written for the Salesforce platform must be checked by unit tests. Salesforce enforces a ‘code coverage’ rule: at least 75% of your code must be checked by a unit test before you can push it into a production org.

Unit testing only tests that code runs correctly - not how well it is written - so it is often used hand-in-hand with static code analysis.

Learn more at:
​https://docs.gearset.com/en/articles/2289356-testing-best-practices
​

An unlocked package - also known as developer-controlled package (DCP) or packaging v2 - is a type of metadata packaging that was introduced as part of Salesforce DX. It's the next iteration of unmanaged packages, and allows more control over which components are added and how to track changes between orgs.

Learn more at:
​https://gearset.com/assets/adopting-salesforce-dx.pdf
​

In Salesforce, a package is just a way of logically organizing chunks of metadata together, similar to putting files into a folder on your computer. This helps developers track related features more easily. Packages can be either managed or unmanaged.

Unmanaged packages are packages created by developers or admins in their own orgs, comprising metadata that they have created or edited. They can see, edit, and deploy it between environments as they wish.

Learn more at:
​https://help.salesforce.com/articleView?id=sharing_apps.htm&type=5
​

User acceptance testing (UAT) is a phase of the software development process when the software is tested by some of the intended end-users, who provide feedback to the development team. UAT testing is used to check that the software fulfills the business functions for which it was designed, and that it can handle real-world cases. Salesforce teams will normally use a UAT org for this purpose before the changes made to the platform are shipped to production.

Learn more at:
​https://en.wikipedia.org/wiki/Acceptance_testing
​

User stories are short descriptions of new software features from the point of view of users. They describe the intended function of new features in simple non-technical language. User stories often provide context for the work of a development team within an agile development process. 

Learn more at:
​https://en.wikipedia.org/wiki/User_story
​

Validation is a function that Salesforce can perform during the process of deploying metadata between orgs. Once a set of metadata changes has been prepared for deployment from one org to another, Salesforce can simulate the behavior of those changes in the new environment without actually deploying them, so you can check that the deployment will work before you actually deploy. 

As part of Gearset’s main metadata deployment flow, you can run Salesforce’s validations from within the Gearset app. Gearset lets you choose which tests to run, and saves the results (failures and successes) in a list of ‘validated packages’.

Learn more at:
​https://docs.gearset.com/en/articles/625156-validated-packages
​

Version control (also referred to as a version control system (VCS) or source control) provides a mechanism for tracking changes to files. Think of it as track changes in Word or Google Docs, but on steroids. For software projects such as Salesforce, this almost always means representing configuration changes as text files (Apex/XML) and tracking changes to those text files over time. Examples of VCSs include GitHub, BitBucket and GitLab. Gearset has native integration with the main Git hosting providers.

Learn more at:
​https://gearset.com/assets/version-control-for-salesforce-whitepaper.pdf
​

Visualforce is a web framework that allows developers to build mobile and desktop apps on the Salesforce platform. The framework makes use of a tag-based markup language similar to HTML and is based on a page-centric model that requires a server to generate a new page each time the user interacts with the app. Salesforce’s newer Lightning Experience framework allows developers to build more interactive and dynamic apps, but Visualforce continues to be used as it’s a tried and tested solution that is easy to implement.

Learn more at:
​https://developer.salesforce.com/docs/atlas.en-us.pages.meta/pages/pages_intro_what_is_it.htm
​

Visual Studio Code (VS Code) is an IDE produced by Microsoft and used to develop and debug modern web and cloud applications.

Salesforce developers use VS Code to help them write code faster and more accurately. VS Code also helps developers navigate the codebase to find what they need, and work with source control to track and release their changes and new features.

Learn more at:
​https://code.visualstudio.com/
​

A webhook is a way for an app to provide other applications with real-time information. This means you can get data back immediately, unlike with typical APIs.

Gearset uses webhooks in a few places. Users can configure CI jobs to run automatically when they commit changes into their source control system. When the branch changes in the VCS it sends a message to Gearset via a webhook, prompting Gearset to run the CI job. Automated notifications from Gearset to applications like Slack and Microsoft Teams also use webhooks.

Learn more at:
​https://sendgrid.com/blog/whats-webhook/
​

XML is the language that Salesforce uses to represent org metadata and custom code. All items of metadata that appear in the comparison results in Gearset are represented in XML.

Learn more at:
​https://www.sitepoint.com/really-good-introduction-xml/