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
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 trying to find a way to migrate all projects (+600) from our Gitlab server to our DevOps platform. Are you aware of any scripts/automation?
Thank you!
I tried different tutorials from Microsoft. They are however designed for single project migration (usually GUI). Yet, in this case, we have multiple users and multiple 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 have recently stepped into the world of DevOps, CI/CD and Automation and I am confused about how artefacts used solely for these purposes are shared and tracked using Version Control, and I haven't really found many resources that cover this topic online.
Some artefacts, such as Dockerfiles, Jenkinsfiles, and .travis.yml, are generally included with the project source code and thus are naturally organised and tracked using Version Control.
However, what if I have a bunch of automation scripts? How can I share/track/bundle my Nginx configuration for a project, or an Ansible Playbook that I use to deploy build artefacts to a bunch of nodes, etc with the rest of my team, or to a future DevOps engineer who might take my place?
However, what if I have a bunch of automation scripts? How can I share/track/bundle my Nginx configuration for a project, or an Ansible Playbook that I use to deploy build artefacts to a bunch of nodes, etc with the rest of my team, or to a future DevOps engineer who might take my place?
Convert your configurations/automation scripts into Sparrow packages then distribute them across teams. There is the nice introduction on that on dev.to . You can use private Sparrow repositories if you concern privacy.
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.