This post is part of the series of posts on the Git and Visual Studio where we are discussing in detail on meaning of basic git operations, how to do them in Git and Visual Studio both and understand the difference of both tools. You can find the previous blog post here.
In this blog post, we’ll learn what is merging, types of merge and how to do the same from git command line.
Microsoft Azure Storage is a cloud offering from Microsoft that provides highly scalable, available, durable storage. Its a part of Microsoft Azure offerings. Azure Storage consists of three data services: Blob storage, File storage, and Queue storage. Blob storage supports both standard and premium storage, with premium storage using only SSDs for the fastest performance possible.
We recently came across this situation, while we were trying to integrate unit testing for one of the applications into VSTS build definition. So strangely enough, all of the test cases were passed but still the task failed:
Many a times, you would need to identify the difference in database schema for two SQL databases so that you can take certain course of action. There are a lot of tools in market which can do this, but you would need to pay for them to get full difference or to use them on continuous basis. However, Microsoft Visual Studio has this functionality built-in for you and if you happen to use Visual Studio as your code development tool, this functionality is basically free. So in this scenario, it also prevents hassle of learning another tool. In this blog post, we’ll learn how to do the same using Visual Studio.
Sometimes, you delete the branch that you were working on thinking that it was not needed later, only to realize that you need it again. If you are familiar with the git bash shell or native git commands, there is nothing much to worry.
It’s possible to restore deleted branch in Git if you happen to remember few basic details. In this quick blog post, we are going to cover on how to restore a deleted branch in Git.
The combination of technical and cultural processes behind databases makes automation difficult. Databases has a state associated with them, so you cannot blow them away like application code and create again from scratch without losing the data. Managing change in a way that doesn’t impact the data is very problematic. Combine that with the cultural issues, the silos, it creates a really difficult problem. There are some general best practices that you can apply to tackle a lot of this complexity, but any time you try to design the solution and get into the technicalities, a lot of time you end up implementing something very specific to a particular type of database. In this blog post, we’ll learn how to use SSDT to implement continuous integration and deployment for SQL database Schema to take some of these worries away.
Any software development team working on a software product generally needs to consume the components either already developed by another team in their organization or another third party organization. So they require a mechanism through which they can create, share and consume the source code. Most often a times, this code is bundled into “packages” that contain compiled code (as DLLs) along with other content needed in the projects that consume these packages.