Im developing 3 Azure Functions called EmployeeAPI, StudentAPI, ProjectsAPI all of which is accessing the same SQL database. I was instructed to make sure that each of projects are deployed separately independent of each other (separate code repository for each).
My problem is there are some common projects that are shared between the 3 and its a pain maintaining all 3 of them. If I changed 1 item let's say a database column, I need to update it on other projects as well.
Is there a way that the common project will reside in 1 repository and the changes will reflect on the 3 projects? Some advised me to create a Nuget package or reference the project.
This is the solution structure of each project (simplified)
EmployeeAPI
ApplicationLayer (shared)
DomainLayer (shared)
InfraLayer (shared)
Tests (shared)
StudentAPI
ApplicationLayer (shared)
DomainLayer (shared)
InfraLayer (shared)
Tests (shared)
ProjectsAPI
ApplicationLayer (shared)
DomainLayer (shared)
InfraLayer (shared)
Tests (shared)
I hope I explained it well :-D
Actually moving shared project to nuget package is the best what you can do if you want to keep API projects in separate repositories. Here you have docs showing you how to push nuget packages to feed.
You can also move all your shared project to 4th repo and the use them as submodule on your API projects. Here you have details about using submodules in Azure DevOps.
Assuming you are using Azure DevOps for CI/CD then you can use path filters like here to include/exclude and have all the functions and shared projects in one repository. Maybe you can achieve similar functionality using other CI/CD tools.
Related
We are currently in the process of migrating from IBM ClearCase as centralized Version Control to Git / Azure DevOps. It is a large and long grown software project in C# with more than 100 C# projects distributed over about a dozen solutions with some dependencies inbetween, at the moment via Project References.
So far all those solutions were managed with ClearCase in a common folder, however for Git it seems to be best practise to use one solution per repo and handle dependencies cross repo with NuGet Packages.
I wanted to ask for experiences in migrating and splitting such projects, did you come across situations where it was better to include multiple C# solutions in a repo?
How do you manage multiple repositories that belong to one software with one release cycle? We plan on using release branches and I think we have to write a script that branches all repositories belonging to the project or is there a more convenient way, maybe provided by Azure DevOps?
I have written before on ClearCase migration to Git.
In all instances, the scenario was the same:
don't import the full history, only major labels or UCM baselines
split VObs per project, each project being one Git repository
revisit what was versioned in Vobs: some large files/binaries might need to be .gitignore'd in the new Git repository.
You can still reference all your Git repository (C# projects) in one parent Git repository, through Git submodules.
You can also go the monorepo route: after all, that is what Microsoft is doing with its "The largest Git repo on the planet".
But in that case, you might need to use Scalar, and sparse checkouts.
See:
"Bring your monorepo down to size with sparse-checkout"
"Make your monorepo feel small with Git’s sparse index"
I'm trying to implement CI/CD using Azure Devops... there are multiple projects in the same solution(local machine)eg: several web projects,angular project with .net core etc
Should i create separate projects in Azure or push them all under a single project by creating a repo in the root directory;i will need to define the build and release pipelines for CI/CD
please advice
I have to build several dozen repositories using Visual Studio Team Services. I have two problems.
How to build repository wich has other external .dll in reference. Can I download it somehow in definition step from sftp or other place?
These repositories have to be build with diferent sets of .dll references. For now we build them changing properties of the project in VS, now we would like to have this functionality in our build definition in VSTS. For example: we would like to build repository with 12.1, 12.2, 12.3 sets of external .dll reference and produce three Artifacts after one pull request.
I have no experience with VSTS, can anybody give me some advice?
In VSTS build, you can only build the sources from one repository for a build. So there are two options you can use:
1. Add external dll into the current repo you need to build.
You can add the dll in your current repo, and then refer the dll from your current repo. Then commit and push the changes and build by VSTS.
2. Add the repo which has the dll you are referring as a submodule for your current git repo.
By adding submodule, you can use the external dll directly. One thing to note, you just need to select checkout submodules in your VSTS build defintion.
I decided to share a small project I have been working on for a while. It's basically a development framework for distributed applications.
Now I'm setting up the GitHub repository and I wanted to use AppVeyor for continuous integration and I'm struggling with the setup.
As for now, my framework is composed of few packages
Interfaces: defines the basic interfaces, extracted as a package so that you don't need to bring the whole framework in your business logic library
Core: contains the basic components of the framework
CastleWindsor: contains support for the Castle IoC container
RabbitMQ: contains the implementation of the engine based on RabbitMQ
Now, it's pretty easy to setup AppVeyor to build and push into Nuget a single project/package.
But what I'm looking is:
build everything on push (includes testing)
create packages and publish them only on a specific action.
I'm wondering if I should create multiple repositories (one for each package) on GitHub and have multiple projects on AppVeyor as well. Or maybe a single repository with multiple projects.
Thanks for your insights.
I've got app 2 solutions (.NET C#) which each share a portable class library (a seperate solution). The app solutions reference the PCL as a project, not by DLL.
What's the best way to deal with this scenario with source control? The portable class library may change for one version of one of the app solutions but not immediately for the other.
I'm not tied to any source control at the moment, I was attempting to do this with TFS but have workspace issues on the portable class library. I'm open for a better suggestion such as Mercurial or Git!
If the updates of your PTL should affect only one application, you can create branches (available with most source controls softwares).
If you have a branch for each application; updates will be visible only in this branch. Then you can use merge tools to update the other one.
Branches are also available in TFS : http://msdn.microsoft.com/en-us/library/ms181425.aspx
For strategies : Branching Strategies
On way is to keep the shared library in a separate area of the source control system. Each project that depends on the shared library will then have to create a branch of the shared library that's specific to the project.
Development is isolated on the branch but you can merge changes on the project branch back to the main branch of the shared library. Other projects that already have branches of the shared library can decide if they want to merge changes to the main branch into their own branch.
You will have to perform some merging when the shared library is updated but using this setup you ensure that each project is isolated from changes performed in the other projects. Each project can decide when they want to upgrade to a newer version of the shared library.