Moving from GitHub to Azure DevOps - A TimCo Retail Manager Video 

You are most welcome. Thanks for watching.

Im having this problem, thanks

Thank you very much! This whole project have been a bit hard to follow due to changes in VS, with a dedicated "Git Changes" explorer and all.

Sounds like a big job (but worth it).

Thanks for sharing.

I'm glad.

I believe the new options for git in VS allows for multiple upstreams.

Thanks for sharing!

Ahh, that's probably why I also didn't have the problem, I was also 'smart enough' to do the whole conversion with Visual Studio closed ;) Never do things like that with the IDE open.

You can't really protect yourself from your own people. Step one is to hire people you trust. Step two is to treat them well. Beyond this, make good backups. You don't need to give developers access to the production systems and you should change all passwords after they leave (even if they leave on the best of terms).

@@IAmTimCorey Thanks

"in case one team member could quit and have the full software source code that could be used to compete with you?" Uhm, that's actually a reason to sue, so don't be too scared about that happening, as it will be easy to prove the person stole the sourcecode. Also the person could have copied the code long before he/she quit. In a small business it's best if most developers know about the other developers work in case they have to take it over (people can quit/die/whatever). It's actually best NOT to have all knowledge of the working with only one person.

Yeah, I'm not sure why VS didn't recognize the open repository as the correct repo. My guess is that it was a bug. The cool thing is that it doesn't matter. Since I had pushed everything up to the repo, I could have deleted the files and re-pulled them without an issue. In this case, I left the files there but cloned the repo to a new folder. No real harm done, just annoying.

There are other SQL DevOps solutions out there, but they are mostly paid solutions. SSDT is probably your best bet if you don't want to spend money.

I don't believe it is because of Visual Studio. I don't know why you aren't seeing changes, though. My guess is that it is something else. I believe at this point we are still on .NET Framework. If that's the case, check that Caliburn Micro is version 3.x and not 4.x.

Maybe try doing a rebuild to clear out the contents of the bin folder and try again.

@@IAmTimCorey I already did that...no joy!

I'm not seeing what you are seeing here. Your repo can go anywhere at any time. There is no lock-in. As I demonstrated in this video, you can move from GitHub to Azure DevOps in a matter of minutes (really less than that if you aren't on camera explaining things). You could do the reverse in the same amount of time or you could go somewhere else entirely. As for your CI/CD pipeline, that's always going to be "locked in" to a vendor unless you are scripting your own process (which I would recommend against). Even if you decided you didn't like "corporate" solutions like GitHub Actions, Azure DevOps Pipelines, or Octopus Deploy, choosing an open source platform like Jenkins still locks you in. If, down the road, Jenkins starts being a problem for you, you have to recreate your build process somewhere else. I've done that exact process. While it isn't as quick as moving repos, it isn't a big deal. You already know what steps need to be taken and most of that is scripted so switching over just means learning the new interface and then setting up what you already have. As for large Azure pricing increases, I've never seen that (and I have the following services running each month: CosmosDB, Azure SQL, Web Apps, Docker instances, Azure Service Bus, Azure Functions, Azure Storage, and a lot more). Azure DevOps, while Azure is in the name, really is a separate entity. It has been free for up to five users for years (going back to when it was called Visual Studio Team Services).

@@IAmTimCorey Ok. Perhaps I'm (unlucky) to have seen 2 big price rises in Azure in 2016: one of around 20 percent, the other at around 12. To be honest, Azure pricing in general is expensive compared to other hosts (Digital Ocean and Linode as examples). I've been around MS devops since it was Team Foundation Services so do have some familiarity. Current pricing wise, MS devops is around 40 percent pricier than our other solution (Bitbucket Pipelines) for a 10 user license model. You mention migration in/out. Question is why would I move to Devops when there are more cost effective options with no vendor lock in and similar functionality? Horses for courses, but I've learned the hard way not to put all eggs in one cloud providers basket. P.S. not a fan of active directory dependency for devops too- more lock in!

Well, I'm never an advocate for a one-size-fits-all solution. You do what works best for you so please don't think I'm trying to convince you away from what works for you. For getting started, Azure DevOps is a free, though, as is Azure Web Apps (up to 10) and SQL databases will cost as little as $5/month. So in this solution, we will have a full CI/CD pipeline, Azure Boards (similar to Jira but included in Azure DevOps), two Azure SQL databases, and an Azure Web App and our total cost will be $10/month (this is for our API - our desktop app will require storage, which will be a few pennies more a month). If we switched our databases to MongoDB Atlas and hosted them on Azure, that would eliminate $10/month in expenses. As for the larger scale like you are talking about, that is probably a better solution as long as you don't want to use Jira (since that will triple your costs). I'm still not sure I understand your definition of "vendor lock-in". You realize Bitbucket is a vendor, right? They are a much smaller company with a lot less resources compared to Microsoft. If we are banking on one organization supporting a product for longer, I'm not thinking BitBucket is the way to go. Again, I don't think that will happen and I'm not encouraging you to go with Microsoft. I'm just confused as to what a "vendor" means. Either company can close down the platform or raise prices. If it happens to you, you would have to move platforms. Not ideal but not the end of the world. Same for me. At the end of the day there are two strategies - either you put all your eggs in one basket or you diversify each part. The latter sounds better because we think of it in terms of the stock market. If one stock dips, the others cover the loss. But that isn't really true here. It is more similar to the parts of an airplane. You might think that getting your engines from one manufacturer, your wings from another and your tail from a third diversifies you but if your engines fail in flight, it doesn't really matter that the wings are still working, the plane is going down. If you host your code on GitHub, use BitBucket for your CI/CD, Azure for your SQL, and AWS for your web app, it doesn't matter which one of these goes down, you have a major problem. Even worse, because you used for vendors instead of one to avoid "lock-in", you are actually hoping that four companies will remain solvent and continue to support their products without rate increases. In some ways, you have actually increased your risks 400%.

​@@IAmTimCorey You make some valid points and provide some food for thought - thank you. As for "vendor lock in", yes I do appreciate that BitBucket is a vendor and that, by using PipeLines, this is also a type of lock-in. However, there are a few meaningful differences / advantages when comparing to Azure DevOps: 1. BitBucket Pipelines is a layer on top of the repository services (Git). Should one get tired of the CI/CD services of Pipelines for whatever reason, these could easily be picked up by something else (e.g. Jenkins self hosted) using web hooks. This is possible because of the standard Git system exposed by BitBucket (and GitHub for that matter). Can DevOps claim the same isolation/compatibility or are there (as I would suspect) some barriers (e.g. AD authentication) that prevent being able to use 3rd party/open source CI/CD systems? There are a few other platforms built with similar architectures (GitLab and OctoDeploy to mention a couple) that have extensibility, flexibility and standards compatibility built in out of the box (unlike DevOps which is proprietary and solely focused on DevOps to Azure pipeline). 2. Using BitBucket (or many other CI/CD pipelines), it is possible to easily target multiple / different target publishing infrastructures and data centers (including but not limited to Azure). This gives complete flexibility and the ability to consider cloud providers are mere commodity providers. To be fair and open, I should mention that in the last 12 months, my company had a cost review which started at our heavy reliance on Azure as sole provider for our cloud based product. This review resulted in a migration away from Azure for most of our compute based resources whist retaining storage (Tables, Blobs, Queues, SQL) in Azure. Today, with most of the compute moved away from Azure, we operate net cost savings of > $1,500 / month whilst maintaining operating integrity and also getting more performance out of better VMs in other data centers. As an example of what I'm talking about regarding proprietary vendor lock-in (and its effects on budget) and one of the problems with the Azure "convenience" platforms (of which I include DevOps as one), take a look at the difference in price of App Service Plan P3V2 as follows (prices valid as of today): * P3V2 (Windows) @ $0.80 / Hr * P3V2 (Linux) @ $0.442 / Hr This shows that, for essentially the same VM (App Service Plans are essentially VMs), Azure is charging almost a 100% uplift for the privilege of running Windows on the App Service Plan. It's this type of messaging (gouging) coming out from Azure that caused us to migrate most of applications away from Azure. I do understand that your tutorial is pitched at the free / introductory tier and therefore costs should be low. However, for anyone considering using Azure in any scale situations, personally I would suggest keeping options open as far as possible about what to put where. Having everything in Azure can (as in my case) be a costly mistake. On the "lock-in" question, you are right in that there is always lock-in somewhere in the chain (even with Open Source solutions). The interesting question (and art) is deciding where to put the lock-in and whom to trust with your overall solution lock-ins. From a cost, reliability and performance perspective my experience has guided towards a more diverse supplier base rather than just Azure.

Two quick things: Azure DevOps can deploy to AWS or any other platform. It can also build non-MS stuff. It really is vendor agnostic. Also, the cost difference for Windows hosting is the Windows license.

It sounds like you have things set up to change the spacing (this is a git configuration issue). Check the changes and see if it is the line breaks that are the changes. If so, change your git settings.

Did you find the answer for this? I am having the same issue

That is an included feature of Visual Studio 2019.

Weird. I've never seen that. A custom rule sounds like it is something specific to your account or PC.

It sounds like a naming issue. When you get a null value back, it usually means that it looked for the value but did not find it. Maybe check that the name is spelled correctly compared to the code that is looking for the name.

@@IAmTimCorey Yes, I had checked naming, but nothing wrong there. The GetTaxRate() method in ConfigHelper is not reading the "taxRate" in the appsettings.json. But don't worry about it -- it may solve itself when we move from config to the API -- it's on your TODO list.

First I like to manually deploy my items so that I know they work. Then I hook up CI/CD. That way if there is a problem, I know the problem is with the build or deploy process, not with the server configuration. So, we will first manually deploy the API, then the SQL databases, then set up CI, then CD for the API. Then we will address the desktop app side of things.

@@IAmTimCorey Thats awesome. Cant wait to see it.

Message=Access to the path 'C:\Users\Minette\Desktop\Learning\IamTimCorey_03-21-21\LearningDevOpsProject\TRMApi\appsettings.json' is denied. This is your issue