In this post I will explain how to create a repository using Sourcetree and upload it to GitHub. As part of this process I will also create a Net Core Web App that would be committed to a remote GitHub repository.
What is required
GitHub Account
Visual Studio
Sourcetree GUI for Git
Let’s start by creating a local repository using Sourcetree
Open Sourcetree and add new tab. On new tab click on Create.
On the next screen we should specify where to create a folder that will hold the repository files. Also an important bit is to tick Create Repository On Account. This way we are creating a connection between your local repository and remote repository that will be created after you confirm details by clicking Create.
If you got to your GitHub account you should see the newly created repository.
You can see that the repository folder together with the Git folder have been created at the location you previously specified.
Next step is to open Visual Studio and create a Net Core Web App.
Make sure you use the app name we used to Create repository since Git is tracking that location.
If you go to the location where you placed your repository. You should see the next picture.
Moreover Git tracked these changes. If you go to Sourcetree this is what you should see.
So let’s click on Stage All, add a commit message and click Commit.
Next step is to push your local changes to remote repository.
And if you got to GitHub again you would see all these changes.
Conclusion
Git is a distributed version control system. In order to become an efficient software engineer/developer you need to understand how it works. This way you can track your changes, always have a copy at a remote location. Which is useful if you need to share this repository with a peer engineer or in case you have lost your local machine copy.
As long as you have initiated the repository you are all set up with version control. Then it’s a case of personal preference. Instead of remembering the location of the repository folder on your machine for creation of the application using Visual Studio. You can simply create an application at one local location and copy over to the folder where you established the repository.
In this post I will explain how to create a repository on Azure DevOps. Clone this very same repository to your local machine and finally commit changes from your local version of repository to remote repository on Azure DevOps.
What is required
Azure Subscription
Net Core Web App
Repository/Repo on Azure DevOps
GUI for Git
Azure offers a free subscription plan for personal use. It’s easy to subscribe and practice for your own development or upskilling for a job.
Let’s start by creating a project that will contain your repository
Once you have created a subscription we can then go to Azure DevOps home to create a project.
Enter the project name that would be used throughout this tutorial. Project is like a root folder that would contain all your applications that are related to this project.
For example you can have a project with name TestProject that contains Net Core web api as a backend and Angular application as a frontend. Then you have another project with name FileProcessing that contains some backend code. These two i.e. TestProject and FileProcessing are two different projects with their own domains. These serve for different purposes. Therefore as a good practice should be placed into separate projects.
Next thing we need to select Repos from the left pane. On the right section of the page it should show you the next view.
In there let’s choose an option to Initialize with a README or gitignore.
And for our benefit let’s add both. This is a good practice and both of these files should be added to every project. README serves as an initial documentation that caughts developers first attention. Gitignore is like a safeguard for committing file types that should be left out from pushing it to a remote copy repository.
After we click Initialize it should redirect us to this repo page. From there we can edit details and perform some useful actions.
One of them which is important for this tutorial is action called Clone. The name speaks for itself. In other words we are taking original remote code and cloning it to our local machine. This way we are creating an exact copy of code at that moment of time. Whatever you do, this code/branch on your local machine would not affect the remote code until the moment you use any of these three main commands: commit/push/merge. There are other useful commands but for them you can perform your personal research and see the effect of them on your code.
Clone repository
Once you are at the main page for your repo click the Clone button.
On the slide out click Copy button.
We need this URL (uniform source locator) in order to clone this repository to our local location on our machine.
For this tutorial I will use Sourcetree as a GUI for Git. In Sourcetree add a new tab or under the File menu option choose Clone / New…
On the new tab choose Clone or if you used the File menu option it shows you the required interface.
Paste in the repository URL into the first field. In the second field select the location where you want this repository code to live. By adding \DummyAzureRepo we are creating a root folder for this repository on the fly. Click
When we click Clone the master branch is cloned to our local machine. As you can see this branch contains only two files that we specified during initialization.
If you edit any of the files from the location where you cloned this repository Git should detect these changes.
Let’s create Net Core App to show how Git detects changes
Create Net Core App
Open up Visual Studio and select ASP .NET Core Web Application with Angular template.
On configuration screen type in the name of our repository and add the location where you cloned it but without the root folder name since it was already created in previous steps when we clone the repo.
This is how the root folder of this repo looks before.
After you click Create on the next screen you can specify a web application template if you need one. For this tutorial let’s choose Angular.
And this is how it should look like after you clicked Create.
Now if you go to Sourcetree you should see these changes.
Click on Stage All, write Commit description and click Commit.
At this point these changes are still only on your local machine. For it to be sent to a remote location you need to use the Push command.
Make sure you ticked the right branch. For your Remote branch you can choose any you like. For this time we will keep it as it is. If you are happy with what you see then click Push.
Once you have clicked Push Git sends these changes to the remote repository.
Conlusion
Being able to use Git is essential for being a successful software developer/engineer. Additionally it helps you to keep track of what has changed in terms of code. Another important point is that you got a copy of your code in the cloud. Centralized location that you or your team member can access from anywhere in the world where you got an internet connection.
In this post I will explain how to setup continuous deployment of Net Core Web App with Azure DevOps for the app that is hosted with Azure App Service.
What is required
Azure Subscription
Net Core Web App
Repository/Repo on Azure DevOps
Let’s start with initiating a repository on Azure DevOps
Prerequisite: you need a project on Azure DevOps. Go to your Azure DevOps main page.
Once you have clicked Create you should see similar screen.
We are interested in Repos section.
Look at the top section of the page where it says Initialize with README or gitignore. In my opinion it is a good practice to have both of these files with every repository you are creating.
With README you are deemed at some point to add some description of your app. This serves as an initial documentation. Whereas gitignore will prevent you from commiting unnecessary files to your repository. In a production environment this save your builds and time in case one or few files has slipped through.
At the end of the day you can always delete them or edit them according to your requirements.
Clone repository
Next thing is to Clone this newly created repository to your machine.
You can use any GUI for Git to do it or even Git Bash if you prefer command line type of application.
For this case I will use Sourcetree . It’s relatively easy to use. Gitextensions is similar in touch and feel. It also nicely connects with various comparison/diff and merge tools.
The main thing for us is to memorize the destination where we clone our reposity.
Create Net Core App
Let’s create Net Core web app with Visual Studio.
Since we already created a solution folder when we cloned the repository to our machine make sure in Location field we target the folder that contains the solution folder named NetCoreWebApp. Visual studio clever enough to place web app files into this folder.
Then we select ASP .Net Core 3.1 with Angular template.
The final folder structure should looke like so.
NetCoreWebApp inside has this structure.
Alternatively you can always create web application at one destination and then simply copy or move it over to the repository location.
In either way the result that we aiming for is for Git to track the changes to the repository.
As you can see Sourcetree on top of Git picked up the changes to your repository.
Steps that you need to do next are:
Good practice is to Build the solution but in this case it can be optional since it’s a pre-made template
Stage All
Write commit message
Commit
Push it to the remote server.
Once all of these steps are performed you would be able to see your changes on your repository at Azure DevOps.
Build pipeline
Select Pipelines from left menu and Use the classic editor.
Then select the repository you wish to setup the build pipeline.
Then you need to choose ASP.NET Core template.
The next screen should look like this.
The only thing that needs changing is on the Triggers tab.
This way we enable Continuous integration. Which means every time you commit changes to this branch it would trigger the build pipeline. As a result you would be able to see whether your changes integrate into the code of remote copy of the branch. In our case it’s master. Normally you would have build pipeline on develop branch before merging and building it on master branch.
Next step is to click on Save & queue. Then we need to add comment, check the branch and click Save and Run.
Resource Group -> Create new, choose whatever name you like since by it you will distonguish resource group that is related to particular project.
Name – which would be part of web app url
Way of publish – Code
Runtime stack that your app would use to run
Operating system – Windows
Region – whatever you like. Mind since we are using free subscription you need to make sure it is available in that region.
Windows Plan -> Create new
Free F1 tier which is part of free subscription from Azure for individual developers that want to research this platform
If you go to your newly created resource and there select App Service. From there you can check the app if it’s ok and running fine by clicking on it’s url.
Let’s go back to Azure DevOps and create Release pipeline.
…before getting into final part I think it’s a good time for a cup of beverage of your choice 😉
Create Release pipeline
Click on Releases from left pane menu. Then click on New pipeline in the area on the right.
Search for Azure app in the search box for templates. Click Apply.
From there you can edit stage details like name and owner. This could be develop stage with one of the testers being the owner. However in our case we will leave these as they are.
We are more interested in editing job/task section. So let’s click on section that is underneath Stage 1 in Stages on the left side.
In here we need to select our Subscription and App service name that we created at Azure portal.
Once we selected and Authorized our subscription we can then see our available App services.
Let’s go back to tab Pipeline and add an Artifact that was created by the build pipeline. Click on Add an artifact.
Select appropriate build pipeline Source. Check alias and edit it if needed. Click Add.
Last bit of setup. The Continuous deployment trigger.
Save and click Create release.
Select the Stage and build version that you want to release.
Once you are happy click Create.
Go to Releases on the left pane. In the right section click on Releases.
You would need to deploy the first release manually. On the next screen click Deploy and off it goes!
You can monitor the process in the next screen.
To check your newly released web app select Deploy Azure App Service.
For this purpose use App Service Application url.
Let’s check out the result! Our Hello, world app! Classic 🙂
Conclusion
Hope you enjoyed this post.
As you have noticed with Azure it is quite straight forward to deploy an app. From creating an App service in portal to creating build pipeline with Azure DevOps. When you have done it once or twice it makes sense. You can easily connect the dots to get the whole picture of modern deployment processes.
In this post I will explain how to setup continuous deployment with Azure DevOps. This post will also contain instructions of how to host it using Azure App Service.
What is required
Azure Subscription
Angular App
Repository/Repo at AzureDevOps
What is continuous deployment?
Continuous deployment is the final stage of CI/CD development approach. It is responsible for deploying code to different environments. For example, develop, staging and production. Deployment happens automatically in comparison to Continuous Delivery. With continuous delivery the only difference is that the release to production happens manually. It involves someone from the engineering team or someone from product team or even management to click a button.
In a nutshell CI/CD is a practice that is followed by an engineer or a group of engineers that work on a common code of any application that is under constant development and which requires to be build, tested and released as soon as the code is being pushed to a git a branch that is responsible for kicking this process off. Normally it is a develop branch.
Main benefit of CI/CD approach is that the code is in deployable state at all times. Of course, this is in theory but in practice this could be more or less true because in order for this approach to be effective team have to be disciplined and implement whatever is required for it. There are a lot of resources online for different situations. This would all depend on the current team approach, requirements and objectives.
Let’s roll up our sleeves and get stuff done
Setup local environment and workspace for Angular app
Install Visual Studio Code on your machine. Please use the below link.
Next thing is to initialize a repository. Select Repos from left panel. If you don’t have any repos in there then you should see similar page.
You need to initialize a repo for it be able to clone to your machine. Once it is cloned you need to copy files your previously created angular app into location where you have cloned the repo to. This way source control app on top of Git will detect changes. By the way you need Git installed on your machine.
*In case you got other repos on the project you can simply add another one like so.
Make sure you give a descriptive repository name. If you want to avoid complications then it should be without spaces. Also select at least README. Alternatively, you can add .gitignore. You can always delete them or replace them. This way your repository won’t be empty and you can check it out with no issues.
Create Azure App Service
Select App Services at Azure portal home screen.
On next screen select Add.
Then select suitable subscription that is available on your account. For this task Free Trial subscription would be sufficient.
Name is App name plus it constructs part of the URL.
In our case the app code will be published, so let’s leave Code as selected option.
Runtime stack relates to this particular instance of app running on an Azure server. Whatever you choose it should be applicable to your application. In other words, your app should be able to run on this stack. Different runtime stack would behave differently, would have different DLLs running and so on.
Depending on the Region you can have different App service plans. For example, since we are using Free Subscription not all regions will have a Free F1 plan and sometimes you need to pick the right one for your needs.
Finally, it should look similar to below image.
Confirm your app settings by clicking Review + create. All done!
Let’s go back to AzureDevops to implement continuous deployment
Create build pipeline
Select Pipelines from the left menu and then click on ‘Use the classic editor’ in the section on the right.
Next select our previously created repository and click Continue.
For our purpose we need an Empty Job where we can customize all the steps and processes for this build pipeline. Other options are premade templates that can speed up pipeline setup.
Next screen should give you different options to structure this pipeline. What we need is to add a task to an Agent Job.
First task would be the Node.js tool installer. You would need to choose an appropriate version to run with your angular app. For example, I will pick version 12.x for Angular 9 app.
Then we need to follow the same pattern and add a npm task.
We need to replace default field content with custom values. In our case we are making sure the pipeline has latest angular installed.
Then we need add another npm task where we explicitly say to install all the packages and dependencies for our Angular app. Here we leave a default field content.
Now we need to add a production build task. Again, we will use npm task.
When app is build using ‘build –prod’ command it creates ‘dist’ folder with app name folder inside. In this folder you got app build files that would be used on the server to run your app.
As you can see on the image below inside we got a folder with app name containing transpiled and minified JS files plus other files required for app to run.
Next step is to archive files into particular location on the server. Let’s search pre-set tasks for an archive task.
And also untick ‘Prepend root folder name to archive paths’.
Last task to add will be to publish build artifacts.
There is nothing that we need to change.
So, the final set of tasks for build pipeline should look like this.
To make it so that every time there is a change to the branch it would trigger a new build we need to select ‘Enable continuous integration’ flag in Triggers section. By doing so we are achieving continuous integration of code.
This looks like it. Now we need to click Save & queue, add save comment and click Save and run.
This will start the build pipeline. During the build all the tasks that we established would be done sequentially.
Create release pipeline
Select Releases under Pipelines in the left side navigation menu.
If you do not have any pipelines you can add a new pipeline by clicking on New Pipeline.
In case you have existing pipelines, you can add new release pipeline by using dropdown as you can see on the image below.
Next thing to add is Azure App Service deployment task.
After that you need to click Tasks tab and select your subscription with app service for this web application.
Once this is done we need to go back to Pipeline tab and select our artifact that we published in the build pipeline.
We keep everything as it is after we choose Source build.
To enable continuous deployment, we need to activate the continuous deployment trigger. Once you have added a build artifact you can click on continuous deployment trigger icon. In the side pop out window you need to set toggle to Enabled.
Additionally, if you got a requirement to set this trigger on particular branch e.g. master, develop etc you can easily do so in the same window. This way the release pipeline will listen to a build on particular branch e.g. develop, yourtestbranch etc
Click Save, then Create release.
Go to Releases on the left pane. In the right section click on your Release created in the previous step.
You would need to deploy the first release manually. Click Deploy
That is it.
Oh, wait one more thing. Go back to Azure portal and find our previously created App Service. Select Configuration from Settings in the left side menu option. Move to the right side and select Path mappings tab. On that tab edit Physical Path under Virtual applications and directories, so that it reads site\wwwroot\dist\ng-app\
This will make sure you are able to access your web application.
Conclusion
This tutorial shows you how to setup CI/CD using Azure portal and Azure DevOps. These two work hand in hand. Since it is all under one Microsoft account it becomes really easy to connect everything together and see results straight away.
CI/CD pipelines serve as handy and straight forward mechanims that can greatly improve the performance of the team. It can also increase the output by automating a lot of processes related to building, testing and deploying of your application.
Dmitri Galejev 