I am developing a game, and am looking for a way to manage version control between two computers. I was directed to use Repos.
I'm new to using version control at all, and when I try to follow tutorials for DevOps it talks about team coordination stuff that is NOT what I'm looking for. Honestly I'm not sure if this is the right solution for me.
I'm really trying to share files between two computers. Not just code, but also textures, meshes, level data, sounds, and ultimately the entire project. (And have a system to push/pull this data between computers, of course.)
I made a project within DevOps, but when I go to "Files" in Repos, I only have options to connect to a Git. How can I select files I need to share? Not just Visual Studio files, but my game's assets and other files?
Or is this even an option? Am I looking at the wrong service here?
You can clone the repository which contain the files you want to share in one project and import this repository in another project.
The document about cloning repo:
https://learn.microsoft.com/en-us/azure/devops/repos/git/clone?view=azure-devops&tabs=visual-studio
The document about importing repo:
https://learn.microsoft.com/en-us/azure/devops/repos/git/import-git-repository?view=azure-devops
Related
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
I'm seeking advice on the following:
In my development shop we support a SASS solution to our customers. We currently have 10 sites that we develop and provide technical support. We're a small team, just 2 of us. We're using Azure DevOps services to host and manage our code, right now we're just using it for a code repo. Within our organization, we multiple projects that represent site. Each site uses the same code base, except the web.config. The web.config is used to change the UI\theme for each customer. When we get a request to create a new site, we first create a new project site and then we copy our code base from the "golden copy" project.
We use a "golden copy" code base to make feature changes and bug fixes. Once we develop a new feature (or fix an issue) to the golden copy, and then we push it to test, QA beings testing. If testing is successful, then the development team copies the entire "golden copy" code files and copies the code to each site project, build and deploy to test for QA to ensure that site works with the new changes . This can be time consuming and prone to errors.
I would like to know the following:
- Is there way in dev ops azure where we merge\copy from our golden
copy to our other site project's repos?
- Can you offer a better way for reorganizing our Organization\Projects
setup based on our current setup\workflow.
Thank you,
As Shayki mentioned, you can consider adopting Git branching strategy. Distributed version control systems like Git give you flexibility in how you use version control to share and manage code.
Keep your branch strategy simple. Build your strategy from these three concepts:
Use feature branches for all new features and bug fixes.
Merge feature branches into the master branch using pull requests.
Keep a high quality, up-to-date master branch.
A strategy that extends these concepts and avoids contradictions will result in a version control workflow for your team that is consistent and easy to follow. For details ,please refer to this official document.
Is there way in dev ops azure where we merge\copy from our golden copy
to our other site project's repos?
For this issue , do you refer to synchronize the changes on the golden copy to other projects' repos? If so, I think it can only be done manually(copy the entire "golden copy" code files to each site project) or clone the entire repo into other projects through the following steps.
In other projects, select the Import repository option:
My company has used a cloud TFS host for many years. Now the host has disappeared from the internet and a lot of code and all history has been lost. There are people working on it so it might be solved but I anyway need to fairly quickly set up new source code handling in Visual Studio Online and need some hints on how to do it.
The current solution was set up long before I started and for various reasons I am currently the only developer. It might change in the future but there will never be more than one developer for each visual studio solution.
I work with many small customer specific projects in Visual Studio (windows application, windows service, WebAPI, SSRS, SQL, Entity framework). The average size of a project is maybe 20 hours from start coding to deployment (there are a few larger projects as well). New features and bug fixes are sometimes added after deployment (can be years later) but that is usually 2-6 hour projects.
The current process has one TFS project per customer and each contain at most a handful Visual Studio solutions. There are no dependencies between the solutions and common code is handled with NuGet.
We had around 250 projects in the cloud and even if I so far only recovered 50 of these, the ones I had locally, we will sooner or later end up with similar numbers. Total size was in the region of 30GB (a lot comes from TFS by default checking in the nuget packages folder)
For most projects there is no need for workitems, kanban, reporting and other ALM features. Only developers will ever use visual studio online. I would like to work with a branch/pull-request/merge process. Coming from Git/Mercurial I have never felt comfortable with TFS.
So my questions are now:
What is a good way to structure the projects?
Single VSTS-project for everything
A VSTS-project for each customer (as today)
A VSTS-project per Visual Studio solution
What is a good way to structure the repositories?
One repository for everything
One repository per customer
One repository per Visual Studio solution
How does Visual Studio and the online portal work with hundreds of projects/repositories where 90% are not active. I usually have 3-5 instances of Visual Studio running with different solutions at any time.
I have read a lot of recommendations but they all seem to deal with long-lived projects and/or team of developers.
My main concerns are:
How much work it is to add a new customer or visual studio solution (happens weekly)
Getting started time. Sometimes an external developer is involved. It is not common but when it happens I don't want them to spend a lot of time on clone/pull (security is not an issue)
Standard. I want the process to follow standard/best practice as much as possible to make it easier to document for other developers. e.g. not encoding information in names of projects or forcing a folder structure.
I will suggest:
Create projects from each customer. Such as you can create projects with customer name like WebAPI, SSRS, SQL etc.
Since a VSTS project belongs to a certain customer related. So all the repositories in the team project should related to the customer. The structure for the repositories can be: different repositories for each case/solution of a customer.
There are only two kinds of version control system hosted on VSTS/TFS: Git and TFVC. And it seems you are familiar with Git and Mercurial, so you can use Git VCS for your projects.
Git repositories hosted on VSTS works as other remote repositories like github, bitbucket etc. it’s bare repo without working directories. So the solutions are not stored but the checksum between two versions and it stored with sha-1 value (40 char). And for most time, you work in local repo (no connect/communication with remote repo). Only when you clone/pull/push, your local git repo will communicate with remote repo.
Project(s) structure: Single project for everything.
Repositories structure: One repository per VS solution
Regarding VS work with these projects/solutions, you can close a solution, then open another solution (You can’t open multiple solutions at the same time in the same instance of VS), you also can just open the file in VS and edit. Regarding commit and push, you can use Git command (e.g. git commit, push)
You need to add them to VSTS when developers are involved, and they need to clone/pull source code from remote.
i have laravel 5.3 project files in developement phase long way to go on live. now one more developer joined me with this. i want share my project via github version control so that we both work on same project without any conflictions. can anyone help me with this how to do it ?
As of now this is not go to the live server.
I am assuming you know git-branching
Also check this
Git branch strategy for small dev team
So, I have a webapp I am creating using the 3 muskateers yeoman, grunt and bower.
My questions are:
What is best practice when it comes to uploading my webapp into a git/mercurial repo? Do I include the entire project? What about directories like 'node_modules' or 'test', etc?
Also, when deploying to live production site: Will my 'dist' folder be what I should be uploading?
With research yielding no results (I could be searching the wrong things?).. I'm a bit new to this process so any feedback is greatly appreciated. Thanks!
You should always commit all of your yeoman, grunt, and bower config files.
There are two schools of thought on committing the output they produce or dependencies they download:
One is, you should upload everything needed for another user to deploy the web app after cloning the repository, without performing any additional operations. The idea is, dependencies may not exist anymore, network connections might be down, etc.
Another is, keep the repository small and don't commit node_modules, etc, since they can be downloaded by the user.
As far as the dist folder goes, yes you'll be uploading it to your server, as it contains all of your minified files. Whether or not you want to commit it to the repository is a separate question. You might let the user build every time, assuming they can get all the dependencies one way or another (from above choice). Or you might want to commit it to tag it with a release version along with your source code.
There's some more discussion on this here: http://addyosmani.com/blog/checking-in-front-end-dependencies/