We are in the process of moving our ~400 projects from SVN to git and are currently evaluating stash as a management tool. We are more or less okay with the migration process itself, but are a bit unsure what kind of project structure would be best for our needs.
Here is how we currently use SVN:
--- application1 [with trunk, branches, tag as subfolders]
---... [about 50 applications]
--- ...[about 50 APIs]
- ... [about 5 other top level folders]
... [about 200 archived projects]
All of our top level folders contain about 50 projects, with the exception of "Archive" which contains about 200 projects. Developers usually work on a subset of about 5-10 projects. Every now and then we create a new project as well as moving old projects into the archive.
We want to keep this basic hierachy because we set up our infrastructure to depend on it (e.g. the release process). Even though we are gradually changing to a more git-ish understanding of our projects, we feel that creating e.g. 'Applications' as a project and simply putting all 50 'real' projects as repos under it doesn't fit our current model of development. Most of them are actually seperate projects by themselves.
We also had a look at the category plugin which adds visual tags to projects. But it's more of an addon that still is in a fairly minor version and not part of stash itself. It seems a bit risky to depend on it.
In summary we are looking for recommendations on how to setup our project structure to fit into stash's project model :)
Looking forward to hearing from you
Thanks for the question.
The most important thing is that you've obvious converted your SVN repository into multiple Git repositories, which is absolutely the right thing to do. The trickest part about migrating is often converting builds to now support the change in layout.
Just out of curiosity, how are you building your indvidual repos now? Do you have a dependency management tool like Maven, or have you gone with something like git submodules? If its the former, then the layout is really irrelevant. On the other hand if your using submodules I can understand why you might be a little more hesitant to get it 'right' in the beginning.
Personally Stash, and most of Atlassian, uses Maven which means we can (and have) moved repositories between servers. For us it's largely about grouping logical things, much like you have, and permissioning for teams. Often we have a project per team (ie Stash, JIRA, etc), but that's just convention.
Certainly if you find category plugin useful, there's no harm in installing it. Stash 2.6 has also added a quick search which might make it easier to find repositories across projects.
Apologies, I know this hasn't necessarily answered your question. Let me know if you need a more detailed response.
thanks for getting back to me.
We are using Maven for building our projects - I totally agree with you that the layout is pretty much irrevelant from atechnical point of view.
I guess the core of my question lays in the practicalities of having 400 projects in a more-or-less flat list.
I already mentioned that we are willing to adopt our project layouts to support the git way of thinking, but with 200+ active projects this is not exactly an overnight process. So I was wondering whether some sort of best practice had already evolved, and someone in a similiar situation (relatively large number of projects + some sort of hierarchy in the project structure) might share his experience with us...
I was kinda hoping someone else might comment with their own experience. How is the evaluation going? Did you settle on a layout for your projects that you were satisfied with?
Just on my previous response, apologies 'irrelevant' might have been too strong a word. But it's good to know you're using maven - that should make your transition to Git all the more easy. As mentioned - we usually split our projects at the team level, which makes permissioning easier and give each team their own space to play in. I couldn't say whether having a single 'Applications' project would be better than creating per-team or per-application projects, it depends on your organisation structure in some ways.
Good luck with the Git migration. I know it can be a little painful, but (IMHO) worth it to get all the benefits of DVCS. I personally couldn't go back to SVN... :)
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot