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.
Customer requests:
- 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.
- Consolidate instances: Acme wants you to tell them the 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.
- 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.
Caveats:
- I have not used GitHub Enterprise
For this customer issue, I recommend starting with a deep dive data gathering session to determine technical parameters within this large monolithic repository, understanding number of files, number of average revisions, number of branches, total storage size, location of the files underpinning the repository, maximum depth of repo, and so on.
Additionally, I recommend a comprehensive inventory of all of the git operations performed by the users of this repo to gather information about the performance of these commands, including average, median and 95% percentile. This data would allow us to classify the operations by the type of user impact and validate the impact on the performance.
Part of the discovery would be interviews with key users of the systems, including representative of each of (Dev Lead, solution Architect, Developer, Test and DevOps engineers). The interview will gather information about their usage of the system and gather desired requirements of the future system.
After the discovery, the services team will distill the findings and recommendations into a detailed plan which will outline the migration steps, describe availability aspects of the system during each of the phases, and describe the target performance goals of the new solution.
For this to succeed, there are two key things: • Achieve both organizational and individual team agreement that this effort is useful, good and helpful • Perform migration cleanly, on schedule and without leaving anything behind
It is imperative is to discover all the uses and purposes of the source code solution in the enterprise to make sure that none are left behind or left dissatisfied with the migration. Considering the "wild west" situation of the repositories hosted "on machines under people's desks", it is important to find them all while carefully bringing independent-minded team owners into the fold of compliance with corporate initiative.
The inventory process will incorporate classification of importance/organizational impact and dependency mapping of parent/child connections. In order to in order to properly determine of organizational impact, it will be very important to identify and develop key champion(s) of this initiative on the company and enlist support of the CxO level management to justify some immediate pain for future plan. In addition to that, I recommend starting a "council"/working group enlisting the key technologists in the organization to support this effort
I recommend running a complete inventory of the teams including all tools available, human and technology.
Soft tools include corporate archeology tools like email/online questionnaires, interviews with key team members and even a printed poster campaign offering bounty for your source control system in the building would be a useful thing, if the buildings were actually used in these COVID-19 times.
The hard tools would be things like network inventory of systems using automated scripts, reports from with endpoint management agents, machine monitoring and maybe even network traffic analysis.
The result will be used to identify the path forward in three phases: • Phase 1 moving 2-3 of most important repositories, and 1/4 of the ones considered less-impact, with evaluation and go-no-go decision before Phase 2 • Phase 2 moving 1/2 of the most important repositories, 1/2 of the ones considered less impact, all the while applying learnings from phase 1 to make the migration complete • Phase 3 moving the rest of the systems and archiving/decommissioning old systems
There should be clear and frequent communication to the stakeholders all through the process via a project web site, mailing list, Slack/Chat tools, and maybe some T-Shirts with quippy messages.
Caveat:
- I have not used SVN, so StackOverflow posts like https://stackoverflow.com/questions/698313/what-is-trunk-branch-and-tag-in-subversion are my friends here
In this scenario, the important thing would be to find the key champion of SVN and win him over/educate him about capabilities of GitHub Enterprise. This would include mapping SVN concepts to their counterparts in Git. For example, "trunk" sounds like a main "branch".
It would be important to understand how many developers are involved in working on the project at the same time, to identify how many "tags" may be involved. During the discussions and demonstrations, we would show how the mapping of that development into "branches" in Git works.
Just like in the first part of the questions, it would be important to perform full inventory of what needs to be moved.
Provided there is a way to move from SVN to Git with preserving history (I think so based on some searches I did), it would be useful to perform example migration of a smaller branch or small SVN repo to GitHub to explain to the customer how it works and demonstrate the results.
Company: Dunder Mifflin Technologies
Version control platform(s): They currently use Gerrit, out-of-the-box Git, Subversion, and Team Foundation Server.
Customer requests:
- 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.
- 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?
- 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.
This company is in a fairly similar place to many established companies that are realizing that their software velocity is not fast enough for the modern marketplace. While at Cisco AppDynamics where my work with observability, performance monitoring and devops journeys, I've seen examples of this kind of situation within financial institutions, insurance carriers, manufacturing companies, car makers, logistic and healthcare industry providers, just to name a handful of industries.
This company is one of many who realize that shipping big releases once a quarter is detrimental to the position in the marketplace and competitiveness within the industry they are in. A more nimble company can swoop in and develop an alternative web site to that of this company within a quarter and take bulk of their customers with them over next quarter, all the while continuously innovating.
I would suggest looking at the reference cases of the other market leaders that have adopted agile practices of developing smaller chunks of features faster, and shipping them at higher cadences. I would want to convince the leadership that adopting more frequent releases over the "heavy waterfall" model would allow addressing of customer problems faster.
If agreed, the journey would incorporate tooling and re-architecture:
- making test-driven development a priority,
- componentizing the main codebase,
- breaking the system into less monolithic chunks
- Designing the system to be services oriented
- investing into Continuous Integration/Continuous Development tooling
- Reviewing potentials of containerization and infrastructure as a service
- Reviewing core vs non-core systems with an eye for buy or license FOSS systems
- Review cloud providers (AWS, Azure, GCP, Red Hat) for useful cost reductions in lift&shift and cloud native development
A human component should not be forgotten, including:
- Self-reflecting and [potentially painfully] explaining that the status quo can no longer be sustained.
- Training the existing long tenured key architects/developers in the modern devops/agile/cicd practices
- Potentially reorganizing development teams into smaller, independent, more agile units
Choosing the right code storage and issue tracking platform an important component of this, although by no means the only one. As a good start, GitHub services should showcase what a modern development team can do with properly set up repository with issues, project tracking, code checkins and integration with the devops tooling (like Azure DevOps and Maven). The customer interest in programmatically enforcing the permissions and driving deployments of the code tree can all be accomplished using the extensive API of GitHub solutions.