We have an application that is comprised of multiple distinct components (different functions / languages).
Is it possible in IBM Bluemix to use a single Track & Plan feature to manage the work items for the components but keep the source code in separate git repositories? For example, I would like to have one backlog for the overall application which is then backed by 5 separate git repos which house the individual components (project-frontend, project-backend, project-queue etc..).
If this is not possible does anybody have a pattern that has worked in streamlining the overall Track & Plan and still enabling the delivery pipeline / managing individual git repos? Ideally I'd like to centralize task management but keep the code distributed.
As of now, there is not a way to manage distributed git repos from a single Track & Plan project in an integrated fashion. That is not to say that it cannot be done manually, but you would need to link to commits in the remote repos in a given work item.
This can be done through the Links tab of any given work item and using the Add SVN Revisions or Add Related Artifacts. This would allow you to link to the remote repos (whether in IDS, GitHub, or private SCM tooling), while still leveraging Track & Plan as an overall planning repo.
Some of this is due to the way projects are constructed in IBM Bluemix DevOps Services today. A single project has the notion of a single git repo, a single Track & Plan instance, and a single Build Pipeline. Some of these requirements are expanding, but the platform provides integration capabilities to work with your code the way you need to right now. For example, project owners can build from remote GitHub repos in the project's Build Pipeline, so that code can be managed as you see fit, but built and deployed on IBM Bluemix.
Related
Our team uses a mono-repo, with several microservices, and some common packages between them.
I am tasked with adding CI/CD automation, and traditionally I rely in Git tags for the sem-ver and utilize comments to decide on major/minor/patch. The semantic-release node library does an good job of automating this.
The problem here is that it is a mono-repo and thus commits and tags are only useful across a global sem-ver. However in my case I have multiple microservices that each will have their own sem-ver.
One thought I have is maintaining a json manifest to store the versions of the services. By blocking direct pushes to the main branch, I can guarentee this file would not be changed on master except by the CI/CD actions.
I also would like to get some ideas from the community on what they would do in this situation? Or what they have done similar to this in the past?
I am starting up a development team within my organization and we are managing all of our initiatives under a single Azure DevOps Project. To be clear I am trying to avoid using the word "projects" here to prevent confusion with the ADO Project terminology, so I am using "initiatives" in this post...
Over time we expect to maintain a large quantity of initiatives (likely hundreds over time) as we cater to many groups across our company. Some of our initiatives will be highly related to each other but should be managed independently for commit histories. For related initiatives we would prefer to manage them under a single Repo but separated into different folders. For example, we may have a dll that will be heavily utilized by many related plug-in like applications. The dll and plug-in applications would preferably be maintained within the same Repo as sub-repos if possible.
Additionally, there will be many categories of related initiatives which would be hosted in other Repo(s).
My question is what is considered best practice to maintain a large number of initiatives, some related and some unrelated, in Azure Repos? I read some things about Git Submodules but am struggling to figure out how to make/manage distinguished submodules in Azure Repos. Is this the best approach, or is it even possible in ADO? Alternatively is it better practice to utilize independent repos for each initiative, and try to group them via a predetermined naming convention and just call upon multiple repositories in the Pipeline?
Thanks in advance! I am relatively new to ADO.
I agree with mason that submodules can be complicated, it is worth effort
Let us say you are developing web app
You have repository "AwesomeApp" that houses code that needs to compile into production code
You could create repo of utilities "UtilitiesRepo"
This repo will never be public and exist just for your convenience
Under the "UtilitiesRepo", you will have some structure similar to following:
scripts/
development_build/AwesomeApp/
.gitmodules
azure_pipelines.yml
Directory "development_build" will become top level copy of "AwesomeApp" using submodules
At top level of "UtilitiesRepo", .gitmodules will have all information to pull down copy of "AwesomeApp" for build/test purposes
[submodule "AwesomeApp"]
path = "development_build/AwesomeApp"
url = https://dev.azure.com/AwesomeApp
branch = CurrentDevBranch
Populate development_build/AwesomeApp with command:
git submodule update --init
Submodule path 'development_build/AwesomeApp': checked out 'CurrentDevBranch'
Now copy of all files will be in development_build/AwesomeApp/
If "AwesomeApp" needs library, you can add that as submodule since directory development_build is just placeholder for copies of other repos
Just add it as submodule and your "scripts" can access and build/test both:
development_build/AppLibrary/
development_build/AwesomeApp/
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
A few years ago, our team made the full transition to Azure DevOps. Before that, we had a mixture of on-prem TFS and Subversion but went to the Azure DevOps as it was easier to maintain project status between our developer and BA teams. At that time, for each project the team was working on, we just created a new "project" in Azure DevOps, but over the course of the past few years, we have found that using that method doesn't lend itself to helping us track metrics across all of those projects. We also see that maintaining multiple, separate backlogs is not ideal as we have developers spread across multiple sprints at the same time in different projects without a single place for the team leads or scrum master to fully know what their team members are working on in a single day.
Now, we've made use of queries, but those only go so far, so we've made the decision to merge our projects into a single "project". My scrum master and I have been looking at Naked Agility's merge tool, as outlined in this link: https://blog.devopsabcs.com/index.php/2019/06/12/one-project-to-rule-them-all/.
Has anyone used this tool and how well did it work for you? Also, are there any other options for merging projects together as this tool seems really complex (which the developer states is the case).
Azure DevOps: Merging two projects together
Sorry for any inconvenience.
I am afraid merging projects into a project is currently not supported in azure devops.
There is a Under Review user voice about make it possible to move a Team Project between Team Project Collections.
Merging two projects is not a simple task, it contains not only source code, build/release history, workitems and other watch outs were mainly around access and security:
External API integrations such as Web Apps, Function Apps, JIRA, Service Now
External inbound app authorisations
External outbound app authorisations such as Azure Service Principals
Variable Group authorisations to YAML Build Pipelines
Library reference updates including KeyVault
etc
This refactoring ended up being much more work than the code merge itself.
Besides, there is a Azure devops extension Migration Tools for Azure DevOps, which allow you to migrate Teams, Work Items, and Plans & Suits from one Project to another in Azure DevOps/TFS both within the same Organisation, and between Organisations. Watch the Video Overview to get you started in 30 minutes. This tool is complicated and its not always easy to discover what you need to do.
Hope this helps.
I am in a microservices project where we are creating around 120 microservices. How do I configure azure devops for this project? Do I have to create a new project for each microservice? I would like to keep the dash for project monitoring
I would recommend that you create an organization and a project.
Then you can use create a git repository for each microservice, 120 microservices in 120 repos.
You can read about how Microsoft uses git here.
TL;DR version quoted below.
Mono Repo or Multi-Repo with Git
It's worth pausing to reflect that this isn't the only way. While
we've elected to have a single monolithic repository (the
"mono-repo"), other products at Microsoft use a multi-repo approach.
Skype, for instance, has hundreds of small repositories that get
stitched together in various combinations to create their many
different clients, services, and tools. Especially for teams embracing
microservices, multi-repo can be the right approach. TFS/Azure DevOps,
like many products at Microsoft, began as a monolith, and its code
organization reflects that