After migrating the work items from one azure devops environment to another. When rerunning the tool, the tool updates the related links but the discussions are not updating. How can we move over new discussions from the old environment?
Discussions are not migrated as they are part of the REST API, and the Azure DevOps Migration Tools use the ObjectModel...
https://nkdagility.github.io/azure-devops-migration-tools/
The gitpod GitHub page says
Gitpod is an open-source Kubernetes application providing prebuilt,
collaborative development environments in your browser - powered by VS
Code.
However, I can not comprehend what it actually does. Can anyone please explain.
Gitpod co-founder here.
Gitpod = server-side-dev-envs + dev-env-as-code + prebuilds + IDE + collaboration.
From a Git Repository on GitHub, Gitlab or Bitbucket, Gitpod can spin up a server-side-dev-environment for you in seconds. That's a docker container that you can fully customize and that includes your source code, git-Terminal, VS Code extensions, your IDE (Theia IDE), etc. The dev environment is enough powerful to run your app and even side-services like databases.
Step (1) is easily repeatable and reproducible because it's automated and version-controlled and shared across the team. We call this dev-environment-as-code. Think of infrastructure-as-code for your dev environment.
After (1), you're immediately ready-to-code, because your workplace is already compiled and all dependencies of your code have been downloaded. Gitpod does that by running your build tools on git-push (like CI/CD would do) and "prebuilds" and store your workspace until you need it. This really shines when reviewing PRs in Gitpod.
Collaboration becomes much easier once your dev environments live server-side and your IDE runs in the browser. Sending a snapshot of your dev environment to a colleague is as easy as sending a URL. The same goes for live shared coding in the same IDE and dev-environments.
At the end of the day, you start treating your dev environments as something ephemeral: You start them, you code, your push your code, and you forget your dev environment. For your next thing, you'll use a fresh dev environment.
The ease of mind that you get from not messing, massaging, and maintaining dev environments on your local machine is incredibly liberating.
Gitpod can be used on gitpod.io, or self-hosted on Kubernetes, GCP, or AWS.
To illustrate Gitpods, note that GitLab 13.5 (October 2020) adds a new feature
Launch Gitpod Workspaces directly from GitLab
Engineers have complicated development environments that can take time to set up and make testing changes or exploring new projects challenging. Often getting started with a project involves following documentation, installing dependencies, and hoping there are no conflicts with other services running. This process can be time consuming, error prone, and may not replicate the configuration accurately to test and contribute to a project.
With Gitpod integrated into GitLab, you can easily launch your Gitpod Workspace directly from the GitLab interface. When editing a project on GitLab, a new dropdown option exists to open that project in GitPod:
Gitpod allows you to define your project’s configuration in code so you can launch a prebuilt development environment with one click.
These environments are configured through a .gitpod.yml file inside of the project and include options for Docker configuration, start tasks, editor extensions and more. This flexible configuration, which is part of the project’s code, allows developers to get started working on a project quickly.
Try this today with the GitLab project which is already setup to work with Gitpod.
Thanks to Cornelius Ludmann from Gitpod for contributing this!
https://about.gitlab.com/images/13_5/phikai-launch-gitpod-editor.gif -- Launch Gitpod from the GitLab UI
See Documentation and Issue.
And with GitLab 14.2 (August 2021)
Launch a preconfigured Gitpod workspace from a merge request
Launch a preconfigured Gitpod workspace from a merge request
The Gitpod integration, introduced in GitLab 13.5, helps you manage your complicated development environments.
Once you define your project’s configuration in code, you can launch a prebuilt, cloud-based development environment with a single click.
This convenient workflow has made it faster than ever to generate new changes, but launching a Gitpod environment to review an existing merge request meant building an environment against the main branch before switching to the target branch and building again.
Now, in GitLab 14.2, you can launch Gitpod directly from the merge request page, preconfigured to use the target branch, to speed up your reviews and reduce the need for context switching.
Enable the Gitpod integration, and your merge requests display a grouped Open in button, so you can open the merge request in either the Web IDE or Gitpod.
Thanks to Cornelius Ludmann from Gitpod for this contribution!
https://about.gitlab.com/images/14_2/create-gitpod-in-mr-view.png -- Launch a preconfigured Gitpod workspace from a merge request
See Documentation and Issue.
GitPod is essentially an ephemerial/adhoc environment that instantiates a Docker container via a .gitpod.Dockerfile yaml. At the core, there is the VS Code integration and the SSH Remote extension is the key piece there that ties a lot of the "what GitPod does" question. In fact, the UI would be another key piece there, as workspaces can be cached via prebuilds (which are available "almost instantly"), or manual "one-off" builds (which take much longer to run - because it's a build - duh), and can be re-instantiated via the UI, which auto-parses stale workspaces after 14 days.
The workspace is the environment. The gitpod/workspace-full Docker image which contains the following at time of this post:
gitpod/workspace-c ✅
gitpod/workspace-clojure ✅
gitpod/workspace-go ✅
gitpod/workspace-java-11 ✅
gitpod/workspace-java-17 ✅
gitpod/workspace-node ✅
gitpod/workspace-node-lts ✅
gitpod/workspace-python ✅
gitpod/workspace-ruby-2 ✅
gitpod/workspace-ruby-3 ✅
gitpod/workspace-ruby-3.0 ✅
gitpod/workspace-ruby-3.1 ✅
gitpod/workspace-rust ✅
gitpod/workspace-elixir ✅
So all in all, as long as the open-source community is active, your getting a pretty fresh, well-provisioned, "full" environment, and it's available "on-demand" via a web UI, that can take a query string with gitpod.io/#{your github url}.
For free, a workspace runs for 1 hour with a total of 50 hours per month avaialble. Increased time and team config is available, so for example, a two-pizza team on a team plan is around $200-$300 per month, which, if you put pen and paper to it, has decent ROI considering time-savings, and amping up the DevX.
I have one DevOps project which has a build pipeline and a release pipeline. creation of build pipeline, DevOps project, container registry, service connection, and Kubernetes cluster is automated using terraform, ARM templates and AZCLI. I could not find any way to store the release pipeline as a code. Is there any way to do that? I want to know how other people are dealing with this? Is there something I am missing?
I could not find any way to store the release pipeline as a code. Is
there any way to do that? I want to know how other people are dealing
with this? Is there something I am missing?
Looks like you're looking for multi-stage Yaml pipelines like Daniel commented above. For now, we can't directly create release pipeline as Yaml format, but we can use multi-stage Yaml for both CI and CD.
To use that option, we need to enable the Multi-stage
pipelines in Preview Features.
You may get more useful info from this issue and this blog. Hope it helps.
Are Bitbucket and Stash the same application?
As far as I understand Bitbucket was called before Stash?
How the moving from one system to the other is done?
As far as I know, the Stash was just renamed to Bitbucket.
I performed the migration from Stash to Bitbucket for one of our clients around a year ago. If my memory serves me right, the process was relatively painless. I first exported the data from Stash using the native export functionality, then I did a fresh Bitbucket install and afterwards just imported the Stash data in the freshly set up instance.
Your mileage may warry though depending on how big the repositories are and from what version are you migrating from. But I'm sure somebody at Atlassian Community forums will be able to help you out if you run into any issues. Or if you have SEN, just write to Atlassian support.
We need to migrate our VSTS team project. I already saw that this is an eagerly awaited feature from the Visual Studio user Voice.
However, in our case the new team project is to be in the same VSTS account. Is there a way to do this while also keeping version control change history? Keeping the change history available as part of the old team project is unfortunately not an option as we will lose access to the old team project soon after migration.
If somebody has done this before with the help of any of the below tools, then it would be great if they can share their experience:
VSTS copy project
VSTS sync migrator
OpsHub
It's a bit unclear what you're about to migrate from where. And why you'd lose access to the existing project. And you have different options based on the current source control type selected.
One option which you could try is to create 2 new accounts and leave the whole old account in read-only state. That should leave the history available to everyone. You can then spin up as many new accounts as you want, using just the latest version of the sources.
Git
If it's a Git repository it's as simple as making a local clone of the whole repo, creating a new team project in VSTS and pushing the clone into its second home.
TFVC
If it's TFVC, it's much harder. I've used OpsHub in the past which works reasonably well, but in our case completely got stuck in a couple of strange merge situations. Those were probably created as part of work done back when that team project was hosted in TFS 2008, so you may be luckier than we were.
You could decide to move to Git as part of your migration. Use git-tfs to create a local git repository with all your TFVC history and then push that into a bare Git repository in your new team project. Or use the TFVC import tool. There's quite a bit of documentation on this subject.
The VSTS Sync Migrator supports a snapshot without history as far as I can tell. Which would not suit you.
VSTS Copy Project doesn't support TFVC, and is no option in this case.
An option that's missing from your list is Timely Migration, it supports TFVC to TFVC migrations among other options. I've used them a long time ago to copy data between TFS servers. Back then they were working exactly as advertised.