Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am in the process of switching to AccuRev from another SCM. I have quite a few projects and am struggling how to properly lay them out in AccuRev.
I have quite a few related projects and would like to keep them in a single depot, but I haven't found out how to separate them so you can keep track of individual projects. In other words, I don't want to have to pull every project at once.
My project layout now is
-Project Group
- Sub project 1
- Sub project 2
-Project 2
-Project etc...
Does anyone have suggestions how to manage these projects in a single depot or should I just go with multiple depots (one for each project)?
The concept in Accurev is that the root of your depot represents all of your source code.
You then create per-project streams (branches) where work is performed, and which themselves may split into further streams (patches, revisions etc).
Users then attach their individual workspaces to these streams and promote changes with their work. These changes are then propagated up the hierarchy as necessary.
Each stream has the ability to filter our content from its parent. This filtered content will be invisible in all child streams or workspaces.
So in your example the users working on "Project 2" would create a "Project 2" stream from the depot, and this stream would filter out "Project etc" and so on.
The best hierarchy I have found for Accurev is something like;
Projects
Project A
Project B
Common
Middleware
Each project then has their own stream that filters out other projects but still keeps the common files.
Accurev is very different to many other SCM packages but it really is an excellent excellent product so stick with it.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Description
The Ansible content organization documentation only talks about a single project with multiple staging environments.
That is great and all, but I need to manage many projects that will be reusing a lot of the same Ansible roles. Should I build a single roles directory and have all of the project specific playbooks point at a "shared" roles directory. Or should each project have a dedicated roles directory containing only the roles related to the project. Below are some of the pros and cons I have thought of for both:
Shared roles directory
Pros:
All roles are in one single location.
For roles that are shared across multiple projects, the role version upgrade will be applied to all projects that depends on it.
Cons:
For roles that are shared across multiple projects, a role version change will need to be tested in every project, even if it is not the project you are working on.
Dedicated roles directory
Pros:
It is clear what roles are needed to run a specific project.
A role version upgrade can be applied to specific projects that require the upgrade.
Cons:
Common roles are copied/cloned many times. However, using ansible-galaxy with requirements.yml file will handle the managment of roles and role dependencies for us.
Question
Has anyone had success with either of this organization strategies?
You've done already a great job with your analysis, outlining most of the elements to take a decision.
Allow me to add a few more considerations.
In general I the right answer has less to do with ansible and more to do with how you're organizing the development of your scripts and roles. Specially in terms what changes when... the different projects and also the different roles.
In an environment where everything evolves disconnected from everything else, you might want to go ansible-galaxy-like (but with your own local repositories). In this scenario you develop the projects' playbooks independently and they reuse the roles defined in the project's requirements.yml. Changes to the roles can be posted to your private galaxy and versioned so that other projects can decide to upgrade or to keep their current version. Roles can be pulled from one or different repositories, but only those required are pulled for each project using the galaxy commands.
In other extreme, if all the projects in your environment evolve in sync, then a central approach will work better as you will have less moving parts. Everything (all roles and playbooks for the different projects) can be stored in a single repository.
At my previous workplace we implemented different playbooks for each microservice. There were about 30 services in production and another 15 in development. Updating and managing the .yml files was not too much of a problem as yaml files are usually short and easy to read.
I'd say it probably depends on how many services, environments as well as developers you are working with!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Currently our main product solution is stored in a single TFS project, and all 3rd-party libraries that are referenced by our projects are pulled in from nuget, so the binary files are not stored in TFS. Now we are having to create a customized fork of one of the libraries (class library) that our product will reference. The library we are going to "fork" lives on codeplex as a TFS/SVN style project that we don't control, so we only have read access to it via the SVN interface, meaning there's no way to do a proper fork like you might be able to do with a git project. As such, our fork has to live elsewhere, disconnected from the codeplex project going forward. Since we use TFS for our main product, we'd like to store the fork and develop it in our TFS environment.
What is the best practice for storing this library in TFS so that our main project can reference it? Should it be in its own TFS Project? How should another project in TFS reference the library?
The team Project is a choice that you will have to make as to which best suits you, either a new stand alone isolated project or whether it just sits with in your current one project, it really depends on how much development work you are going to do with it and whether you want to be able to manage that through the same sprints etc.
To consume it i would just build it and create a NuGet Package and consume it in the same way as you do with all the rest of your referenced projects, obviously you may need to have this in your own NuGet feed.
If this is the only project that requires this customized library, put it in a folder inside of your current project that is parallel to your Sources (now cloaking is not required). Create a manual triggered build definition that builds the library and creats a NuGet package. Use a post-build script (or modify nuget.target) to push that NuGet library to your NuGet repository. Then reference this in your daily build.
You can overlay new releases from codeplex in your folder structure, if needed.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm the sole developer working on a couple of webapp sites. I have them in subversion, but I'm not using a project management tool.
I recently got redmine up and going, and I want to set up the projects in there. What I'm looking for is a recommendation as to how to structure these two projects in Redmine. From what I can glean, the structure is Project->subproject . So I'm trying to map this to my to-do list structure. From my to-do list, there are three kinds of tasks: new features, bug fixes, and maintenance ( not quite bug fixes but things that really need cleanup ).
Should I make each webapp a top-level project, with Features, Bugs, and Maintenance as subprojects? What other ways of organizing projects are there? For instance, in the subversion manual, they recommend having project/trunk, project/branches, project/testing, project/releases, etc. Are there similar guidelines for working in Redmine?
As usual, when you configure a system you need to customise it as much as possible to try and meet your own needs. I personally don't know of any guidelines or recommendations for Redmine per-se, however I can relate what we do here and I hope that will help you! :-)
Features/Bugs/Maintenance are just ways to label your tasks so that you can filter them. These are a specific label known as a "tracker" in Redmine. You can define your own trackers for additional types of task.
Project and Sub-Project are also effectively a way of labelling your tasks, but grouping them under a broader umbrella category. When you create 'projects', you assign the trackers you will need to them. In our case, we create an API, and have distinct trackers to identify bugs, features & modifications with (effectively) duplicated tracker names so that we can identify if the tasks are for desktop or dsp programmers. The sub-projects are used to identify product lines or customisations that our customers require specific support for. We also use version labels to identify specific releases in each subproject so that we can get a nice roadmap view of all of the tasks we are tracking. We have multiple projects in our Redmine system, each configured in a similar manner, with some project tasks linked across projects as "related" issues so that we can identify dependencies.
This is just one way to configure Redmine, but is the simplest we could manage given the complex relationships between some of our projects. It is the second configuration that we have tried and we find it works well. FYI, the first configuration was on a test system to allow us to work out what we needed from the system after migrating from Trac, a couple of years ago. The current configuration has been in use for about 2 years and seems to suit our needs nicely.
As I said earlier, you need to decide what you need from the system, but the simplest approach is to think about how you view a project from the top down, configure your system to match your processes, and not change your processes to match the tool - always the more 'disastrous' option IMHO. I wouldn't recommend tracking bugs and features etc in separate projects, as getting your roadmaps together is usually harder, and it also makes it harder to visualise the total task load for a given project. Even dividing task types into subprojects could be problematic, as it complicates things if you find you need to support multiple product release cycles, adding to your workload in terms of managing your Redmine system.
That's about all I can think of for now. I hope that helps you. :-)
The kind of tasks you mention seems to be what Redmine calls tracker. You can define your own trackers. In my opinion, you shouldn't need a sub-project for each "kind of task", but a tracker.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm getting ready to implement a source control system (subversion) but I'm facing some doubts on how to structure my folders.
I use Delphi for all my development and compile the projects from within the IDE.
My current projects folder structure is as follows:
-E:\Work\1. Shared
--Forms (shared forms across all projects)
--Units (shared units/classes across all projects including 3rd party like JCL)
-E:\Work\2. Company Name
--Admin (stuff related with admin work like a license keys generator, Windows CGI to handle order processing automatically, all developed in Delphi)
--Projects
----ProjectA
-----5.x (version 5.x)
------BIN (where all the binaries for this project go)
------Build Manager (where the FinalBuilder project lives)
-------Install (NSIS file that create the setup.exe)
-------Protection (Project files to protect the compiled exe)
-------Update (inf files related with the auto-update)
------Docs (where the readme.txt, license.txt and history.txt that are included in the setup file are)
-------Defects (docs for any testing done by me or others)
-------HTMLHelp (html help for the project)
------R&D (where screenshots, design ideas and other R&D stuff goes to)
------Releases (when building a release with FinalBuilder the setup file created by nsis is placed here)
------Resources (Images and other resources used by this project)
------Source (if a sub-project exists it will compile to BIN since they are all related)
-------SubprojectA
-------SubprojectB
-------SubprojectC
--Sites
--- companywebsite.com (the only one at the moment but if we decide to have individual web sites for products they would all be placed on the Sites folder)
The sign "-" marks directories.
Anyone cares to comment about the current structure or has any suggestions to improve it?
Thanks!
Having setup literally hundreds of projects over the years, and having specialized in software configuration management and release engineering, I would recommend that you first focus on how you want to build/release your project(s).
If you only use an IDE to build (compile and package) your project(s), then you might as well just follow the conventions typical for that IDE, plus any "best practices" you may find.
However, I would strongly recommend that you do not build only with an IDE, or even at all. Instead, create an automated build/release script using one or more of the many wonderful open-source tools available. Since you appear to be targeting Windows, I recommend starting with a look at Ant, Ivy, and the appropriate xUnit (jUnit for Java, nUnit for .NET, etc.) for testing.
Once you start down that path, you will find lots of advice regarding project structure, designing your build scripts, testing, etc. Rather than overwhelm you with detailed advice now, I will simply leave you with that suggestion--you will readily find answers to your question there, as well as find a whole lot more questions worth investigating.
Enjoy!
Based on comments, it seems that some detail is needed.
A particular recommendation that I would make is that you separate your codebase into individual subprojects that each produce a single deliverable. The main application (.EXE) should be one, any supporting binaries would each be separate projects, the installer would be a separate project, etc.
Each project produces a single primary deliverable: an .EXE, a .DLL, a .HLP, etc. That deliverable is "published" to a single, shared, local, output directory.
Make a directory tree where the subprojects are peers (no depth or hierarchy, because it does not help), and do NOT let projects "reach" into each other's subtree--each project should be completely independent, with dependencies ONLY on the primary deliverables of the other subprojects, referenced in the shared output directory.
Do NOT create a hierarchy of build scripts that invoke each other, I did and found that it does not add value but does exponentially increase the maintenance effort. Instead, make a continuous integration script that invokes your stand-alone build script, but first does a clean checkout into a temporary directory.
Do NOT commit any deliverables or dependencies into source control--not your build output, not the libraries that you use, etc. Use Ivy against a Maven-like binary repository that you deploy separate from source control, and publish your own deliverables to it for sharing within your organization.
Oh, and don't use Maven--it is too complicated, obfuscates the build process, and therefore is not cost-effective to customize.
I am moving towards SCons, BuildBot, Ant, Ivy, nAnt, etc. based on my target platform.
I have been composing a whitepaper on this topic, which I see may have an audience.
EDIT: Please see my detailed answer to How do you organize your version control repository?
why the 5.x? (under projectA)
I don't think it is useful to introduce the versions in the tree - that is what subversion, etc is for.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I'd be leading a new project soon. And I've been pondering over what are the basic infrastructure for a software project. These are the stuff that I think every project should have:
-Coding style conventions
-Naming conventions
-Standard project directory structure(eg maven standard dir layout, etc)
-Project management and issue tracking(eg trac, redmine, etc)
-Continuous Integration server(eg, hudson, cruise control, etc)
I'm not sure if I missed out anything. Would anyone like to add?
As a preliminary answer, check out the Joel test:
http://www.joelonsoftware.com/articles/fog0000000043.html
Just an appetizer:
Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?
revision control system (eg. subversion, cvs, git)
In addition to yours I will put:
Unit Test Strategy
Integration Test Strategy
Defined Process
Release (delivery) strategy (like milestones, working packages and so on)
Source control branching strategy
What about documentation - how (comments in code, high-level specs), when, amount, who
How you will test - unit/acceptance/user testing
code versioning, some SVN/Git (or is it included in trac?)
team roles and responsibilities - need to be done in ocntext of your project
Knowledge management is crucial. As you already plan to use wiki (like Trac or Redmine) you could use it for KM as well.
Functional testing is a mandatory part of any project. Unit testing is great and it works well for Agile projects but the functional testing is still necessary. You need at least a basic Test Plan. If you plan to have multiple projects or sub-projects a Test Strategy document or Wiki page would be good.
Test Cases, Acceptance Test Cases etc could be driven by your User Stories or their equivalents but they still have to exist in some form.
I would throw a file sharing server into the mix too. I thought version control was so basic, that I didn't even bother to put it there in the list. But its a good point version control.
Configuration Management Plan. You need to have a documented approach to your development workstreams, how you will be merging between then, etc.