From practice - separated deployments have a couple of additional benefits. You version each app, not the solution. You also have much better and robust interfaces between them (you are basically conditioned to be very mindful of breaking changes). On top of that - integration tests become much easier (and much more needed). But overall - the smaller you do things - the easier they are to operate and maintain.
Thanks Tim for the great project, i can't wait the rest of it. just a little suggestion, if you can make some changes to the business logic and add some complex scenarios it would be much better because in real life this is what we are suffering from. Thanks again and keep it up.
@@IAmTimCorey It is seriously good content. You teach practical things and describe real world problems. It is one thing to know about all of the pieces, but its rare to find content where somebody takes the gargantuan effort of showing how those pieces fit together in a real world scenario, and explaining why things are done certain ways.
Probably the better way to do this is to have multiple agent jobs (inside one pipeline), one for each project. This has the benefit of being able to set different agent pools for each project => doing the API build on ubuntu-16.04 is almost 4 times faster than windows-2019 (40 sec. vs. 2m 30s)
Many ways to skin the cat. Another option is to go back to build the solution which will build all your projects, and then adding additional publish tasks grabbing the files from each other project. There's also a zip task if you want to zip them up.
The benefit to multiple pipelines is you can have a release for each pipeline. Although, you may be able to define a release for each project. Although, I think 99% of the time, you are going to deploy your API and Db projects together.
I wish you Happy Easter Tim! I have learned so much in the whole course, thank you Tim! I can't wait for the next video, this one was great too! Quick question, the property in the build section for SQL, is that for deploying to the Azure SQL Databases directly? I had to switch to Google Cloud SQL because of the current Microsoft "rules". I could only build if I removed the property. And also, is the API directly deployed (updated) when build succeded, or I have to publish manually from VS again? Thank you!
Happy Easter to you as well. In this video, we aren't deploying anything. We are just creating a build. Deployment will come later so there is no tie to Azure SQL, etc.
Hi Tim, great Video again. I am wondering how many retail Management Apps are suddenly popping up on Azure. :-) Currently i am trying to figure out how to so localization in .net Core. As a suggestion for future content, i would really like to see your approach within the TimCo App. Thx for the course and great content.
Hi Tim, Thank you for the high quality video ! In my job I work on a multi-project solution (~30 projects or more). The CI pipeline is done using TFS. However, it is not automated. I have a build definition. To launch a build, it has to be done manually : specify the project variable, the server where it should be deployed ... I searched for a better way to do this, but in vain. What can you advise me to do in order to transform this pipeline to an automated one (build the project modified whenever a push or pull request is fired. Thank you.
What happens if the URL to the API changes (perhaps you need to move to a new server) after the WPF app has been deployed? Do you have to manually change the app.config file on every machine running the WPF application so that it can look for the correct API URL?
Hi Tim! I can't get the pipeline to work. I'm getting this error (MSBUILD : error MSB1008: Only one project can be specified.) when on "Build Sql Project" task. Neither the WPF project is building. I've triple checked all and can not figure out what's wrong. Any ideas?
Update: Got it working. Somehow the character combination in MSBuild parameters caused an escape sequence. Might be better if MS would provide some sort of tool for entering those build parameters.
