I have many repositories which is works with the same teamcity config. Now I use different teamcity projects for each rep. Is it posible to create one teamcity projects with all these repositories? And how to do that?
Related
Help needed with azure pipelines. Just testing it and consider migrating from TeamCity to Azure Dev and was wondering:
I have:
1. Asp.Net Core Web Api (Web1)
2. Asp.Net Core Web Api (Web2)
3. WPF App
4. Several infrastructure class libraries that are shared libs between the above 3 solutions (Web1, Web2, WPF).
Do I create 4 azure projects?
1 project that includes the repository of Web1 project with 1 pipeline that nuget restores, builds and publish artifacts
1 project that includes the repository of Web1 project with 1 pipeline that nuget restores, builds and publish artifacts
1 project that includes the repository of WPF App with 1 pipeline that nuget restores, builds and publish artifacts
1 project that includes all repositories of all class libs and for each library I create a pipeline
or I create one project for all and add one pipeline for each (web1, web2, wpf apps and class libs)
Writing the comments as an answer so that we can close the question.
Are those .NET projects located on different git repositories? Is your git tool Github or Azure Devops repos?
Personally I use projects to seperate different logical projects (development teams) and different pipelines inside the same project for different projects of the team.
For example team A could have 4 projects, I would go for one DevOps project and 4 pipelines inside it. Team B would have a separate project etc.
Shared libraries can be handled the same way as different projects. You can build them and upload them through a task on nuget. If they should be included on the projects, there should be already on your web1,web2 and wpf projects, as a result the pipeline that will execute msbuild and nuget restore will handle the libraries also.
If you do not want to eliminate some projects to specific people, then I would go for one DevOps project and different pipelines for each library project.
In general you combine the pipeline with a github repository. As a result if all your libraries are placed inside one github repository you will go with one pipeline, else you have to create multiple pipelines inside the same Azure Devops Project.
In general the approach that I mainly use:
Different Azure DevOps projects -> Different dev teams.
Projects inside one dev team -> Different pipelines inside the project.
Different github repositories -> Different pipelines for each one (exceptions apply here but in most cases it is a practice)
My team wants to separate our snapshots by which environment they should deploy to. We have a Development, Stage, and Test environment. We have a Maven Repository called BASE. I would like to deploy our snapshots to BASE/Develop, BASE/Stage, etc
How can I create a repository path like this? When I try to set the mvn deploy -DaltSnapshotDeploymentRepository=repoID::default::https://artifactory/BASE/Develop I get an error Return code is: 409, ReasonPhrase: Conflict.
If I remove the Develop, it works fine.
Is there any way to do this?
The common practice for that in Artifactory is using different local repositories for different lifecycle states. Then use build promotion in order to move your artifacts through the lifecycle states. Use a virtual repository, aggregating the other repositories, in order to use a single source to resolve your dependencies.
For more details and examples, see:
Onboarding Best Practices: JFrog Artifactory
Knowledge Base: How Does Build Promotion work
White Paper - Best Practices for Structuring and Naming Artifactory Repositories
Documentation on Maven repositories in Artifactory
In a project I'm planning to have following items/projects:
.Net Server, Ionic App, Angular Website and a C# Admin tool.
At first I made a project, created one repository and folders; Server, App, Website and AdminTool in the root. But as I want to use pipelines and structure my code best possible way, I'm thinking it might have some advantages creating a repository for each project, in my project.
This way I will trigger exactly the pipeline of the project which needs to be build and it might be more module structured.
But I also see the disadvantage of having to push multiple times for the same feature - Each for each involved project (e.g. IonicApp and Server). This way it's not that clear what is made across projects for one feature, which could be seen in one push.
Which way to structure this would you recommend?
Generally, a Git repository on Azure Repos should be no larger than 10GB. This aims to ensure reliability and availability for all customers.
If you put too many projects into one repository, and these projects may also contain some large files, it may dramatically increase the time to checkout, branch, fetch, and clone your code. This could bring you a bad experience with Git. For more details, you can see "Git limits".
So, in your case, maybe you can consider using Submodules.
Create a repository for the main project.
Create a repository for each sub-project.
Set the repositories of sub-projects as the submodules of the main project's repository.
For the source codes of the features that are involved in multiple projects, you also can set up a specific repository for each feature, and then set the feature repositories as submodules of the involved project repositories.
With this way, you can set up the pipeline for each repository. And you also can using the "pipeline-completion triggers" feature when you want the changes in the submodule repositories also can trigger the pipelines for the repositories that is using the submodules.
A separate repository for each project is highly recommended and considered best practice.
With this you will have benefits, like;
smaller sized repos,
every project integration with CICD separately.
Because at the moment you will be updating single app project, so why to bother other running projects
In VSTS I have 2 Git projects (ProjectA,ProjectB). If ProjectA is updated then automated build is triggered. I would also like ProjectB to trigger also after ProjectA. How do I configure this in VSTS?
I check the trigger section but I not Build completion Add option is disabled. Is this the feature I should be using?
Although the build system supports chained builds, those builds must reside within the same team project. Team Projects are intended for isolation of unrelated resources with no dependencies. Since you have dependencies between these repos, ideally, they should not be in separate team projects.
Some options:
Script it using the REST APIs.
Make a build definition in Team Project A for the repo hosted in Team Project B, then use chained builds.
Host your related repos and build/release definitions in the same team project.
How do I configure m2eclipse ( maven plugin for eclipse ) to use a centralized maven repository that is also used in jenkins.
The default user settings in m2eclipse is something like "home/user/.m2"
How can we do something like "ssh user#192.168.1.200:/var/lib/jenkins/.m2"?
A neat and easy way to do it is to use a repository manager. Sonatype's Nexus seems to be the most popular, but there are others (e.g. JFrog Artifactory and Apache Archiva). They run as HTTP servers, and you can change your Maven configuration (both locally and for Jenkins) to use it as a mirror for any Maven repository (e.g. the Central Maven repo), or use it to host your own repositories.
There is no need to do that. Your POM files list dependencies and they list repositories. Maven will then resolve your dependencies against all known repositories (the listed ones and the "build-in" ones, like Maven central).
Maven will do this in m2eclipse, when running a Maven build. Maven will also do that when running the build on Jenkins. So if both machines can connect to all the repositories listed in your POM files, both will retrieve the same artifacts and both will do the same builds.
You should really not try to share the local copy of the artifacts. That is as bad as if I and you try to share our Maven artifacts using a network share. Maven is designed to find and manage those artifacts and you are trying to do its job with this question.