lifecycle models Questions

I am looking for pros and cons of manual testing in 2023

Dear Experts,

Need your expter advice in setting up a new repository structure for our product development.

We have a software product, with 15-compnents and each of the 15-components have at least 15-modules.

Earlier our admin guy had configured the Stash server for us.

The current setup is like this:
Our IT engineer had created 15-Projects in stash/bitbucket server for 15-Components
For each of the 15-modules in a given component, a individual repository was created

Thus we have around 225 + 25(for additional module), totally 250 repositories to manage.

Individual developers creates their feature branches on their respective repositories and merge them to their production branch in their respective repo, after release.

Feature branches gets created only on a particular module in a particular repository which is getting affected for that feature.

If a developer is working on a feature, which is affecting 10-modules, this developer creates a branch in each of the repository which is affectting this module. Thus he creates 10-branches for a given feature in 10-different repositories.

In this way, we have many small teams working on many individual repositories corresponding to their module. Packages are made from each of the individual repository and delivered to our infra team, who deploys the product on our hosted servers.

Since source is spread all over the place, there is no baselines/tags created for this product. Also managing these many repositories by a single CM admin is too much to handle.

As a CM admin, I’m thinking of suggesting this structure for this product.
Create a single Project (Project A) in Stash 
Create a single repository (Repo A ) in this project 
Create a folder for each Component, i.e 15-Folders, under the repository root 
(i.e Project A - /RepoA/Component1/Module1 Module2 ……Module15
/RepoA/Component2/Module1 Module2 ……Module15
/RepoA/Component3/Module1 Module2 ……Module15
:
:
/RepoA/Folder15/Module1 Module2 ……Module15)

In this way we’ll have single repository to handle and CM admin will create branches and developers will just make changes and commit their code.

Appreciate your response on these lines:

1. Is my suggestion to host a single repository for all the components correct? 
is this achievable, what is your opinion on this repository structure?

2. We are developing a multi-tier, web application using PHP, Python, and Java Script. This application gets deployed on multiple servers. By using this single repository structure, do you see any issue or obstacle at a later stage on the line of development? What precautions should we take, if any?

3. Since the application is multi-tier, developers actually develop the application in the development environment (where multiple servers are setup to create a production sort of environment) using the shared work area in the environment, at times there are chances of one developer overwriting the others' changes.

What is your opinion on this kind of development?

4. Using this repository structure, how do we resolve the conflicts? Whenever a developer tries to push/pull the changes, he/she might face multiple conflicts not only from their changes. Should we call all developers to assemble at one desk and resolve the conflicts or is there any other better way?

5. We have many set of features getting developed on different branches. At times, many components are not modified in the some branches, still we just package them and release. What is your advice on this?

As CM admin, I see lots of advantages in managing branches and merges in a single repository structure. What do you suggest for our kind of development.

I have read many articles on web about the advantages/disadvantages of having single/multiple repositories. My Dev team is not conveienced with my approach.  Thus I need answers to all my(actually their's) question in one place.

Would appreciate your detailed response for each of the above issues that we are facing.  Your assistance in this regard will be very much appreciated.

Eagerly awaiting your response.

 

Thanking you,

Deepak.

I'm have promarily used Subversion in the past, and the structure we used was:

/branches    - Self evident name for branch management

   /int          - Integration branches

      /projectA_effort_q4_2014 - Integration branch for release on q4 of 2014

   /usr         - Individual engineers branches

      /fred    - Fred's set of branches

         /some_bug - Fred's branched from somewhere to fix some bug

      /sally    - Sally's set of branches

         /some_feature - Sally's branched from somewhere to add some feature

/tags          - Self evident name for tagging

   /projectA_v1.0 - Tag of projectA at version 1.0

/trunk         - Trunk for various projects

   /projectA  - ProjectA

   /projectB  - ProjectB

/vendor      - Repo path for storing pristine drops of 3rd party code used in various projects

   /acme     - Vendor name of a 3rd party source of code

      /superLib - Acme provides us the superLib

         /current - Latest drop of superLib

         /v1.0_drop - Tagged drop of superLib

         /v1.1_drop - Tagged drop of superLib

 

The machanics of this is to allow for segregated development with maximum traceablity. For example any propriatary changes specific to a project needed within superLib would happen within that project, and only the pristine changes from the vendor would be within the /vendor area, then merged into the project to minimise merge errors.  Users brnach off the integration branches to their own staging areas in usr to integrate new functionality of fix issues and merge them back into the integration branches once proven.  The CM, PM, EM, and PVM would be responcible for merging the integration branch to the trunk project and tagging the trunk project versions.

 

Our current system is TFS based, and is really porrly managed - it was a historical conversion from ClearCase to TFS and there is no clear deliniation as described above.  In fact, it's more like a shot gun of tags and branches, without a really good organzation of where the root of changes should reside, and there's multiple code forks even though 90% of the code is shared.
I was looking to see if it makes sence to refactor the release structure into something like the above, but I'm not sure if it makes sense for TFS and the documentation I can find on TFS doesn't really describe best practices or typical work flows, and the rest of the users here are actually more familier with ClearCase as TFS was a corporate edict of standardization that was pushed onto them.
If you are familier with a better flow or best practice for TFS, please share as our current structure is unmaintainable and unscallable for validation and test purposes.

Thanks much,

-J

By Frank Monden - December 6, 20131 Answer

Tools

By Bob Aiello - March 10, 20137 Answers

Hi everyone,

my esteemed colleague Marc Bools and I have started working on bringing back the CM Wiki and we want you to help us with the design and requirements of a new CM Wiki!!!

Here is a hight level list of the topics from the old wiki. This is your chance to help!!

Topics you will find in the CM web 

Definitions: 

  • Configuration Management 
  • Software Configuration Management 
  • Build Management 
  • Change Management 

Tools: 

  • CM Tools - Software and tools for Change and Configuration Control - HCM/SCM 
  • CM Integrations - Integration of CM tools with other tools 
  • Frequently Asked Questions 

Concepts and theories: 

  • ConfigurationManagementBodyOfKnowledge (a.k.a. CMBoK ™) 
  • CM versus SCM - Thoughts on the differences between the terms CM and SCM 
  • CM Metrics - What you could gain in time and money when using CM. 
  • CM Metaphors and Analogies -- metaphors and analogies for describing CM 

Processes and practices: 

  • Agile Development and Agile SCM - Ideas on Agile Development and how it affects CM 
  • Configuration Management Process 
  • Change Management Process 
  • Branching and Merging for Parallel Development 
  • CM and Web Engineering 
  • CM and Databases 

Templates and Examples: 

  • CM Templates - Quick templates to help you start implementing a CM solution 

Vendors: 

  • TBD 

Other: 

  • Suite Vs Best Of Breed 
  • SCM Readings - Some recommended SCM books and papers 
  • History of CM 
  • WhosWhoInSCM  

Starting points

  • TBD 

What other topics should we include?? How do we provide more value from our new and improved CM Wiki.

Drop me a line and get involved!

Bob Aiello
Editor in Chief
[email protected]

Hi Everyone!

this is a great time to get involved with CM Crossroads by submitting your own articles on software and systems development. CM Crossroads has always had a strong focus on Configuration Management within the full software and systems lifecycle and this means that we are interested in articles on a wide array of topics. Contact me directly to get involved with submitting your own articles and I will help you with getting started, forming your ideas and editing your article for publication.

Common topics include:

  • Build and Release Engineering
  • Source Code Management including branching and streams
  • Deployment Engineering (DevOps)
  • Development in the Cloud
  • Configuration Management (including the CMDB)
  • Continuous Integration and Deployment
  • Environment Management
  • Change Management

    and much more! 

    Bob Aiello
    Editor in Chief
    [email protected]

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.