0:08 thank you
0:11 hello synapse LCD fans
0:13 welcome to this video series on synapse
0:16 ICD my name is Hui kunye and I'm a
0:18 support escalation engineer on the Azure
0:20 synapse analytics team
0:22 integrating your workspace with the
0:25 distributed Version Control System like
0:27 kit will give you the flexibility you
0:30 need to share and managed code
0:33 when altering your code in synapse
0:35 Studio your team should find a balance
0:39 between this flexibility and the need to
0:41 collaborate and share code in a
0:43 consistent manner all team members
0:46 should publish review and iterate on
0:49 code changes through git branches shared
0:52 with others in synapse you should adopt
0:55 a branching strategy for your team so
0:57 they can collaborate better and spend
1:01 less time managing Version Control and
1:03 more time developing their code
1:06 in this video we'll be demonstrating how
1:09 you can keep your branching strategy in
1:11 synapse very simple
1:13 implementing some Concepts that will
1:16 result in a Version Control workflow for
1:19 your team that is consistent and easy to follow
1:20 follow
1:22 let's watch the demo and see how you can
1:24 achieve this
1:26 working collaboratively and tracking
1:28 code changes in synapse Studio can be
1:30 quite challenging
1:32 you can look at synapse Studio as a
1:34 front-end to an integrated analytics
1:38 platform here we combine
1:40 date warehousing
1:43 big data analytics data integration
1:46 visualization so having
1:48 multi-disciplinary teams here
1:50 interacting with all these cap
1:53 capabilities in different projects
1:55 different features it will require to
1:57 collaborate and share code in a
1:59 consistent manner
2:01 this is where adopting a simple
2:04 branching strategy for your team is key
2:06 for a successful continuous integration
2:10 of your code in synapse Studio
2:12 you want to apply a branching strategy
2:15 that avoids contradictions
2:16 will result in a Version Control
2:18 workflow for your team that is
2:21 consistent and easy to follow
2:24 in this video I will show you a simple
2:26 Branch strategy that you can adopt in synapse
2:28 synapse
2:31 so let's start by using feature branches
2:34 feature branches or topics
2:36 topics
2:38 they are helpful when you want to
2:41 isolate your work in progress from the
2:44 completed work in your main branch
2:47 when you hit the branch selector here in
2:50 synapse Studio you can differentiate
2:52 this collaboration Branch from other
2:54 feature branches
2:57 by this icon here with this blue star
3:00 this Branch represents your
3:03 collaboration Branch your shared code base
3:04 base
3:07 you want to keep this Branch a high
3:12 quality and up-to-date Branch okay this
3:14 is the branch that you want
3:18 to build cleanly and always be correct
3:21 your main branch needs these qualities
3:24 so that your feature branches created by
3:27 your developers they start from a good
3:30 known version of a code
3:34 so you need to prevent as much
3:36 interactions with this Branch direct check-ins
3:38 check-ins
3:41 and the feature Branch they will do the work
3:42 work
3:46 so to create this feature branch
3:48 you can use this Branch selector in
3:50 synapse and click here
3:52 on the new branch
3:56 and you can create a branch based on
3:58 whatever Branch you have here
4:01 in synapse Studio the workspace publish
4:03 branch is not editable
4:06 so it will not appear here in this
4:09 Branch list so right now since I have
4:11 this main branch only
4:14 I will create my feature branch
4:17 and I can you can give for example
4:21 your developer's name and then
4:24 feature one for example
4:26 as a naming convention
4:30 so I'm going to create this branch
4:31 and now
4:34 in the branch selector you can see this
4:38 Branch already and if you go here to
4:42 devops repo you will see under my folder
4:45 name my feature branch and this feature
4:49 Branch was create based on Main so all
4:53 the folder structure that exists in main
4:57 branch will be replicated to my feature branch
4:59 branch
5:01 so now
5:04 I'm ready to start on a new feature
5:07 so suppose that I want to create a new
5:09 SQL script
5:12 okay based on my serverless pool simple
5:16 slip script like select one plus one
5:18 for example
5:26 I will see these changes reflected here
5:29 in my feature Branch under the SQL
5:39 now look at the publish button that is
5:42 disabled from any branch except your
5:44 collaboration branch
5:48 so you cannot publish your code from a
5:51 feature Branch only from collaboration
5:55 now that's where the second step for
5:58 your branches branching strategy comes
6:02 in using pull requests
6:05 so now you need to merge your feature
6:07 Branch into the main branch using a pull request
6:09 request
6:13 in pull requests you can use code review
6:15 and the review that takes place in a
6:18 pull request is critical for improving
6:20 code quality
6:22 you should only merge your branches
6:25 through a pull request that pass your
6:27 review process
6:29 to create a pull request in synapse
6:33 Studio you can use the branch selector
6:35 and select the create pull request
6:37 option here
6:41 and by using this pull requests you can
6:44 merge your changes from your Source
6:46 Branch into destination in this case
6:49 from my feature Branch into my
6:50 collaboration branch
6:54 and you can see the files involved in
6:56 this pull request
6:58 you can review this code
7:02 you can see the commit as well
7:07 and you can ask your reviewers to
7:09 approve this this pull request as a best
7:12 practice you can link this full request
7:15 to any work any work item
7:18 okay in this case
7:21 I I have this process as much simple as
7:24 possible so I don't have any code
7:27 reviewer right now I'm keeping this
7:28 process simple
7:32 but you should have these reviewers in
7:34 place okay
7:38 for the approval process to to start
7:40 so now I'm going to approve my pull request
7:42 request
7:46 and to complete when I complete I can
7:49 select here the merge type I will keep
7:52 this as the as the standard merge no
7:55 fast forward and in terms of post
7:57 completion options
8:01 I hope to delete my feature Branch after
8:04 merging I don't want to keep
8:07 too much feature branches here in my in
8:10 my branching strategy to avoid any
8:12 garbage so
8:16 in the in the in the repo in this case I
8:19 don't need the feature Branch anymore so
8:21 I will delete after completing the pull request
8:23 request
8:26 so now when I complete the pull request
8:29 my merge my changes from feature Branch
8:31 will be merged
8:35 to my collaboration Branch Main and now
8:38 that is pull request is completed I
8:41 added my SQL script I can close this
8:45 window and when I switch to the main branch
8:46 branch
8:49 here in
8:51 synapse Studio
8:54 I will see my SQL script one
8:58 here available in this branch and the
9:03 publish button will now be enabled so I can
9:04 can
9:06 publish my changes
9:10 one thing that you can do prior to the
9:13 publish operation is just to use the validate
9:14 validate
9:16 all link
9:20 to start the workspace validation and
9:21 see if there is any inconsistent code
9:25 before publishing your changes
9:27 now that the workspace validation is
9:30 clear so I'm going to hit the publish
9:33 button and here it is
9:35 depending changes
9:37 that were flat
9:40 depending on the changes that
9:42 were merged to the
9:45 main branch or the collaboration Branch
9:47 you will see these painting changes
9:49 reflected here
9:52 so now I'm going to
9:55 hit the publish button for my pending
9:58 changes only the SQL script will be
10:00 published and once the SQL script is
10:02 published to live mode
10:05 the publish operation will start the
10:07 second stage let's call it this way the
10:09 arm template generation to the publish branch
10:11 branch
10:15 so now the publish operation
10:17 save this SQL script
10:20 in the service live mode
10:23 so here it is the SQL script one
10:26 it was saved in live mode and
10:27 and
10:31 if we go here to the branches in the
10:33 workspace publish
10:36 we should see under the workspace name
10:37 the folder
10:41 you should see that templates the two
10:44 arm templates generated by the publish operation
10:46 operation
10:48 and this will be the outcome of your
10:51 continuous integration
10:54 workflow let's call it this way in
10:55 synapse Studio
10:58 These Arm templates they represent the
11:00 outcome of your continuous integration
11:03 life cycle and synapse
11:07 and they will represent the input
11:09 the starting point for your continuous delivery
11:11 delivery
11:15 of artifacts in synapse
11:17 we will see this continuous delivery
11:20 stage in a later stage
11:23 in another video
11:26 thanks for watching this video we would
11:28 love to hear from you don't forget to
11:31 like comment and subscribe to our Channel
11:32 Channel
11:34 thanks again for watching and I will
11:36 catch you up on the next one [Music]
