Company: Acme computers
Version control platform(s): Many GitHub Enterprise instances installed throughout the company by different teams. Acme Computers is trying to standardize on GitHub Enterprise and consolidate their GitHub usage onto a single instance. The company has many instances of other Git hosting solutions installed as well. Some are fully supported applications. Other instances are on machines under people's desks.
Shrink large repository: Acme wants GitHub to help them shrink the large repository to a more manageable size that is performant for common Git operations. The large repo is a project that is high visibility with an aggressive roadmap. They request that we help them within the month. It's a large, monolithic repository.
1. Identify the contents of the repository. Depending on the contents, there are different ways to shrink the size of the repository. Also determine the original size - git count-objects -v should give an idea as to the size.
2. Before any work is done against the repository, a complete backup should be performed. Because this project has “high visibility,” it is important that the current flow not be interrupted until an acceptable solution is tested. I would recommend performing all work on a clone of the repository so that it does not affect work until it has been tested.
3. Remove all stale branches from the repository. This can be done by using git gc prune.
4. Perform an git gc aggressive to perform further cleaning and optimization on the repository.
5. Once the test instance has proven to be effective, a branch will be created from the repository complete the cleaning noted above. When the cleaning is complete, the branch will be merged into a stable branch.
6. While the cleaning is being performed, we can assume new development will not stop since there is an “aggressive roadmap.” All development will be done in their respective branches. Once the cleaning is complete, they will perform a git pull, resolve all merge conflicts, then merge their development branch to the stable branch.
https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-gc.html
Consolidate instances: Acme wants you to tell them best way to move all the other teams, using GitHub Enterprise or other Git solutions, onto their consolidated GitHub Enterprise instance. They have asked you to give them five or six bullet points about how you would approach that initiative, both technically and culturally.
1. First, we need to get a sense of what is being moved. One point of contact from each team should list out their repositories and their current git solution, if any. This would give a overview as to the amount of work needing to be done.
2. Before migrating any repository, a complete backup should be taken.
3. GitHub has recommendation for several tools to be used for source code migration. Using on of these would be the most efficient way to migrate.
4. Once the migrations are complete, each team would be assigned appropriate accesses to their respective repository. This would allow each team to own their own work.
5. Having multiple teams on a single GitHub Enterprise instance allows for collaboration, code reviews, and a real time activity stream. This provides more efficiency, more knowledge sharing, and more accountability both inside each team and across teams.
6. Having one central location for all the projects would make the introduction of a CI tool, such as Jenkins, much easier and more effective. The set up time would be very short while providing a long term solution for project building and deployment.
https://help.github.com/articles/source-code-migration-tools/
Migrate an SVN repo: The customer has one SVN repository that hasn't migrated over to a Git solution. They would like help moving this one large repository over. The team has a trunk based development pattern with this repository and is unfamiliar with Git.
1. GitHub has a recommended tool for migrating SVN repositories to GitHub repositories.
2. We might look at shrinking this repository down since it is “one large” repository. A smaller repository will make migration easier.
3. Because of the foundational differences in trunk based development versus Git flow, it would be wise to conduct some training for this team. Part of the training should include a simple project that can be used as hands on training. This would provide a safe, working environment that is already in place.
Company: Dunder Mifflin Technologies
Version control platform(s): They currently use Gerrit, out-of-the-box Git, Subversion, and Team Foundation Server.
Help us modernize our practices: Dunder Mifflin is worried they are falling behind their industry. They have lots of legacy software and development patterns that were created 20 years ago. They have found it incredibly difficult to change any aspect of their SDLC because of their infrastructure, processes, and long-tenured team members who are resistant to change.
Moving to a single enterprise solution that everyone uses increases time and efficiency. It does not create more work. In addition to the increase in efficiency, the collaboration between team members organically increases due to built in practices in GitHub Enterprise (Activity Stream, code reviews, sign off before merge). Since the software is legacy (over 20 years old), it might be a good time to review the software functionality and see if the application can either be refactored or rewritten in a more modern language. The inclusion of a CI tool will also decrease manual, monotonous tasks and automate the software build process. These changes will modernize the software development process as well as update the infrastructure and process to the SDLC.
Another important option would be to discuss their software development process. Since we talking about legacy equipment, it might be safe to assume that their process is legacy as well. Introducing and training the team on Agile / Scrum software methodologies would be a high priority. Coupling modern processes with modern tools will increase their efficiency.
Help us release more often: Dunder Mifflin releases software four times a year. They are shipping largely web-based applications. They want to increase more frequently, but they are unsure of the best first steps. What areas would you explore with the customer to help them move this goal forward?
A strong CI tool such as Jenkins would help with more frequent application released. A CI tool assists in releasing more quickly because it automates the build process, ensures there is a working piece of software by running tests, and if the tests fail, reverts the merge to the last commit. I would want to create a simple proof of concept to demonstrate the capabilities and to train the users before the implementation moves forward into a production environment.
As mentioned in the previous point, moving to a Agile / Scrum methodology would help position the team to release the software more frequently. Since the maximum sprint time in Scrum is one month, we could potentially move the team from releasing four time a year to twelve times a year without any major disruptions.
Commit/merge/deploy permissions: Dunder Mifflin has expressed concern about moving away from Gerrit. They have asked how they can control repository access, merging, and deployment permissions within GitHub, and what aspects of their desired security setup can be enforced programmatically.
GitHub Enterprise allows repository access to be controlled by LDAP roles and groups. These can be defined inside of the LDAP service and then enforced inside of GitHub Enterprise. LDAP sync must also be enabled in order to ensure the most current changes in the LDAP service is reflected in GitHub permissions. If LDAP sync is not enabled, the account must be manually synced. The LDAP feature would work better for a large network of teams.
If LDAP is not an option, accesses can be assigned within each repository, allowing the team to decide who has access and who doesn’t. This might work better for a small network of teams.
https://help.github.com/enterprise/2.15/admin/guides/user-management/using-ldap/