search

dougmcclure / ILA-Open-Beta

Expiriments with ILA and DevOps, IT Operations and Automation Tools
1 stars 1 forks source link

Decide on Project git repository structure #9

Closed c835722 closed 11 years ago

c835722 commented 11 years ago

Issue:Complexity. In the repository the file system directory structure is being used to reflect a point in time view of the project. This leads to significant complexity (in code, documentation and understanding) which is a barrier to entry for the project. eg1. Scenario1 directory. eg2. CentOS58 directory. eg3. The blog also refers to using the /Scenario1/box1/Vagrantfile to bring up the standalone box which is confusing when its has nothing to do with Scenario1.

Proposed enhancement. Remove these directories and refactor repository in an attempt to standardise the associated development workflow. Create a singular shared directory within the repository and move components into it. Update the instructions in the README.md to reflect the change in instructions to be the approximate of :

git clone repo onto local machine.
download ILA driver from intenet into /shared on local machine.
cd /box1 && vagrant up. To bring up single box scenario.
cd /box2 && vagrant up. To bring up multi box scenario.

Utilise git tags to reflect point in time features. The blog can then point at the tag to download the repo image that reflects the blog entry. As the blog rolls on, the main branch is updated to reflect the latest, but previous entries each have a tag to reflect the main branch at that point in time allowing the user to implement each experiment historically if desired.

c835722 commented 11 years ago

Here is a working version of the repo with refactoring. https://github.com/c835722/ILA-Open-Beta Feel free to clone it locally and validate the workflow is simplified. It can be refined here or if your ok I can send you a pull request and the changes can be accepted into your repo.

dougmcclure commented 11 years ago

Testing this now.

dougmcclure commented 11 years ago

ok, seemed to work fine for me. I like the simplicity.

Can you think of anything we should rename, relocate, etc. I'd like a good naming scheme for the provisioning scripts that shows their function - order - role in a scenario, etc. Same for directories holding stuff unique to one box or scenario.

Let me know what has to happen to synch this to mine. The next step would then to create a branch from that as the development area for the updates I want to do for the new milestone d2. Does the tag come in after that gets merged into the master again?

Thanks for you awesome help & mentoring. If you let me know then I can synch before I get on the plan home in the AM (for a lovely 8 hours...)

Doug

c835722 commented 11 years ago

I think the script names should reflect the generalisation of the deployment unit they pertain to rather than the product name. The product names (which keep changing) defeat people trying to understand what the "solution" provides. So my suggestion would be to refactor the provisioning scripts around how the deployment unit participates. eg. syslog-server, application-server. These terms the vast majority of the public understand whereas SCAA and ILA not so much.

For the synch I suggest: Create a new branch to keep a copy of your existing master for posterity/blog sake. (Can be deleted later) I will lodge a pull request with your github repo from my repo for the synch of my current master. Delete redundant branches on your repo (Scenario1)

Then from that point on its gitflow method. Use 'develop" to add feature request branches, then cut a release to "master" when you are happy and probably when it aligns with a new blog entry.

I will get that pull request underway now given your travel plans. Then I will start a branch to have a look at the refactoring of the script names as discussed above.

Cheers.

c835722 commented 11 years ago

Main project repo updated with this structure. Closing issues. Will open distinct enhancement request for script names.