Modify typos

Author: liudan66

articles/synapse-analytics/cicd/continuous-integration-delivery.md

@@ -28,7 +28,7 @@ To automate the deployment of an Azure Synapse workspace to multiple environment
 - Prepare an Azure DevOps project for running the release pipeline.
 - [Grant any users who will check in code Basic access at the organization level](/azure/devops/organizations/accounts/add-organization-users?view=azure-devops&tabs=preview-page&preserve-view=true), so they can see the repository.
 - Grant Owner permission to the Azure Synapse repository.
-- Make sure that you've created a self-hosted Azure DevOps VM agent or use an Azure DevOps hosted agent.
+- Make sure that you've created a self-hosted Azure DevOps VM agent or use an Azure DevOps hosted agent. 
 - Grant permissions to [create an Azure Resource Manager service connection for the resource group](/azure/devops/pipelines/library/service-endpoints?view=azure-devops&tabs=yaml&preserve-view=true).
 - An Azure Active Directory (Azure AD) administrator must [install the Azure DevOps Synapse Workspace Deployment Agent extension in the Azure DevOps organization](/azure/devops/marketplace/install-extension).
 - Create or nominate an existing service account for the pipeline to run as. You can use a personal access token instead of a service account, but your pipelines won't work after the user account is deleted.
@@ -186,7 +186,7 @@ The deployment task supports 3 types of operations,  validate only, deploy and v
 **Validate and deploy** can be used to directly deploy the workspace from non-publish branch with the artifact root folder. 
 
    > [!NOTE]
-   > Please make sure you have the endpoint **web.azuresynapse.net** whitelisted when the operation type is selected as **Validate** or **Validate and deploy** if network policies are enabled on the VM.
+   > The deployment task needs to download dependency JS files from this endpoint **web.azuresynapse.net** when the operation type is selected as **Validate** or **Validate and deploy**. Please ensure the endpoint **web.azuresynapse.net** is allowed if network policies are enabled on the VM.
 
 **Deploy**  The inputs of the operation deploy include Synapse workspace template and parameter template, which can be created after publishing in the workspace publish branch or after the validation. It is same as the version 1.x. 
 

articles/synapse-analytics/cicd/source-control.md

@@ -15,7 +15,7 @@ ms.reviewer: pimorano
 
 By default, Synapse Studio authors directly against the Synapse service. If you have a need for collaboration using Git for source control, Synapse Studio allows you to associate your workspace with a Git repository, Azure DevOps, or GitHub. 
 
-This article will outline how to configure and work in a Synapse workspace with git repository enabled. And we also highlight some best practices and a troubleshooting guide.
+This article outlines how to configure and work in a Synapse workspace with git repository enabled. And we also highlight some best practices and a troubleshooting guide.
 
 > [!NOTE]
 >To use GitHub in Azure Gov and Azure China, you can bring your own GitHub OAuth application in Synapse Studio for git integration. The configure experience is same with ADF. You can refer to the [announcement blog](https://techcommunity.microsoft.com/t5/azure-data-factory/cicd-improvements-with-github-support-in-azure-government-and/ba-p/2686918).
@@ -91,7 +91,7 @@ For more info about connecting Azure Repos to your organization's Active Directo
 
 ### Use a cross tenant Azure DevOps account
 
-When your Azure DevOps is not in the same tenant as the Synapse workspace, you can configure the workspace with your cross tenant Azure DevOps account with the guide below.  
+When your Azure DevOps isn't in the same tenant as the Synapse workspace, you can configure the workspace with cross tenant Azure DevOps account.
 
 1. Select the **Cross tenant sign in** option and click **Continue** 
 
@@ -150,13 +150,13 @@ Connecting to a GitHub organization requires the organization to grant permissio
 
 If you're connecting to GitHub from Synapse Studio for the first time, follow these steps to connect to a GitHub organization.
 
-1. In the Git configuration pane, enter the organization name in the *GitHub Account* field. A prompt to login into GitHub will appear. 
+1. In the Git configuration pane, enter the organization name in the *GitHub Account* field. A prompt to login into GitHub appears. 
 
 1. Login using your user credentials. 
 
-1. You'll be asked to authorize Synapse as an application called *Azure Synapse*. On this screen, you will see an option to grant permission for Synapse to access the organization. If you don't see the option to grant permission, ask an admin to manually grant the permission through GitHub.
+1. You are asked to authorize Synapse as an application called *Azure Synapse*. On this screen, you see an option to grant permission for Synapse to access the organization. If you don't see the option to grant permission, ask an admin to manually grant the permission through GitHub.
 
-Once you follow these steps, your workspace will be able to connect to both public and private repositories within your organization. If you are unable to connect, try clearing the browser cache and retrying.
+Once you follow these steps, your workspace is able to connect to both public and private repositories within your organization. If you're unable to connect, try clearing the browser cache and retrying.
 
 #### Already connected to GitHub using a personal account
 
@@ -174,11 +174,11 @@ If you have already connected to GitHub and only granted permission to access a
 
     ![Grant organization permission](media/grant-organization-permission.png)
 
-Once you complete these steps, your workspace will be able to connect to both public and private repositories within your organization.
+Once you complete these steps, your workspace is able to connect to both public and private repositories within your organization.
 
 ## Version control
 
-Version control systems (also known as _source control_) allows developers to collaborate on code and track changes.Source control is an essential tool for multi-developer projects.
+Version control systems (also known as _source control_) allow developers to collaborate on code and track changes. Source control is an essential tool for multi-developer projects.
 
 ### Creating feature branches
 
@@ -190,30 +190,30 @@ Once the new branch pane appears, enter the name of your feature branch and sele
 
 ![Create branch based on private branch ](media/create-branch-from-private-branch.png)
 
-When you are ready to merge the changes from your feature branch to your collaboration branch, click on the branch dropdown and select **Create pull request**. This action takes you to Git provider where you can raise pull requests, do code reviews, and merge changes to your collaboration branch. You are only allowed to publish to the Synapse service from your collaboration branch. 
+When you're ready to merge the changes from your feature branch to your collaboration branch, click on the branch dropdown and select **Create pull request**. This action takes you to Git provider where you can raise pull requests, do code reviews, and merge changes to your collaboration branch. You're only allowed to publish to the Synapse service from your collaboration branch. 
 
 ![Create a new pull request](media/create-pull-request.png)
 
 ### Configure publishing settings
 
-By default, Synapse Studio generates the workspace templates and saves them into a branch called `workspace_publish`. To configure a custom publish branch, add a `publish_config.json` file to the root folder in the collaboration branch. When publishing, Synapse Studio reads this file, looks for the field `publishBranch`, and saves workspace template files to the specified location. If the branch doesn't exist, Synapse Studio will automatically create it. And example of what this file looks like is below:
+By default, Synapse Studio generates the workspace templates and saves them into a branch called `workspace_publish`. To configure a custom publish branch, add a `publish_config.json` file to the root folder in the collaboration branch. When you publishing, Synapse Studio reads this file, looks for the field `publishBranch`, and saves workspace template files to the specified location. If the branch doesn't exist, Synapse Studio would automatically create it. And example of what this file looks like is below:
 
 ```json
 {
     "publishBranch": "workspace_publish"
 }
 ```
 
-Synapse Studio can only have one publish branch at a time. When you specify a new publish branch, the previous publish branch would not been deleted. If you want to remove the previous publish branch, delete it manually.
+Synapse Studio can only have one publish branch at a time. When you specify a new publish branch, the original publish branch would not been deleted. If you want to remove the previous publish branch, delete it manually.
 
 
 ### Publish code changes
 
-After merging changes to the collaboration branch , click **Publish** to manually publish your code changes in the collaboration branch to the Synapse service.
+After merging changes to the collaboration branch, click **Publish** to manually publish your code changes in the collaboration branch to the Synapse service.
 
 ![Publish changes](media/gitmode-publish.png)
 
-A side pane will open where you confirm that the publish branch and pending changes are correct. Once you verify your changes, click **OK** to confirm the publish.
+A side pane opens where you confirm that the publish branch and pending changes are correct. Once you verify your changes, click **OK** to confirm the publish.
 
 ![Confirm the correct publish branch](media/publish-change.png)
 
@@ -231,21 +231,21 @@ Enter your workspace name and click **Disconnect** to remove the Git repository
 After you remove the association with the current repo, you can configure your Git settings to use a different repo and then import existing resources to the new repo.
 
 > [!IMPORTANT]
-> Removing Git configuration from a workspace doesn't delete anything from the repository. Synapse workspace will contain all published resources. You can continue to edit the workspace directly against the service.
+> Removing Git configuration from a workspace doesn't delete anything from the repository. Synapse workspace contains all published resources. You can continue to edit the workspace directly against the service.
 
 ## Best practices for Git integration
 
--   **Permissions**. After you have a git repository connected to your workspace, anyone who can access to your git repo with any role in your workspace will be able to update artifacts, like sql script, notebook,spark job definition, dataset, dataflow and pipeline in git mode. Typically you don't want every team member to have permissions to update workspace. 
+-   **Permissions**. After you have a git repository connected to your workspace, anyone who can access to your git repo with any role in your workspace is able to update artifacts, like sql script, notebook, spark job definition, dataset, dataflow and pipeline in git mode. Typically you don't want every team member to have permissions to update workspace. 
 Only grant git repository permission to Synapse workspace artifact authors. 
--   **Collaboration**. It's recommended to not allow direct check-ins to the collaboration branch. This restriction can help prevent bugs as every check-in will go through a pull request review process described in [Creating feature branches](source-control.md#creating-feature-branches).
--   **Synapse live mode**. After publishing in git mode,  all changes will be reflected in Synapse live mode. In Synapse live mode, publishing is disabled. And you can view, run artifacts in live mode if you have been granted the right permission. 
--   **Edit artifacts in Studio**. Synapse studio is the only place you can enable workspace source control and sync changes to git automatically. Any change via SDK, PowerShell, will not be synced to git. We recommend you always edit artifact in Studio when git is enabled.
+-   **Collaboration**. It's recommended to not allow direct check-ins to the collaboration branch. This restriction can help prevent bugs as every check-in goes through a pull request review process described in [Creating feature branches](source-control.md#creating-feature-branches).
+-   **Synapse live mode**. After publishing in git mode,  all changes are reflected in Synapse live mode. In Synapse live mode, publishing is disabled. And you can view, run artifacts in live mode if you have been granted the right permission. 
+-   **Edit artifacts in Studio**. Synapse studio is the only place you can enable workspace source control and sync changes to git automatically. Any change via SDK, PowerShell,is not synced to git. We recommend you always edit artifact in Studio when git is enabled.
 
 ## Troubleshooting git integration
 
 ### Access to git mode 
 
-If you have been granted the permission to the GitHub git repository linked with your workspace, but you can not access to Git mode: 
+If you have been granted the permission to the GitHub git repository linked with your workspace, but you cannot access to Git mode: 
 
 1. Clear your cache and refresh the page. 
 
@@ -264,8 +264,8 @@ If the publish branch is out of sync with the collaboration branch and contains
 ## Unsupported features
 
 - Synapse Studio doesn't allow cherry-picking of commits or selective publishing of resources. 
-- Synapse Studio doesn't support customize commit message.
-- By design, delete action in Studio will be committed to git directly
+- Synapse Studio doesn't support self-customized commit message.
+- By design, delete action in Studio is committed to git directly
 
 ## Next steps