Skip to content

Instantly share code, notes, and snippets.

@z0r1k

z0r1k/GitHubEnterprise.md

Last active May 22, 2018 13:27
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save z0r1k/beba96afa92afeb86e0af1f89b185859 to your computer and use it in GitHub Desktop.
Save z0r1k/beba96afa92afeb86e0af1f89b185859 to your computer and use it in GitHub Desktop.
Download ZIP
My take on GitHub Enterprise challenge.
Raw
GitHubEnterprise.md

Prompt #1

  • Company: Acme Computers Inc.
  • 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 peope's desks.
  • Performance: The single instance of GitHub Enterprise occassionally has reports from users of being slow. There are 5,000 of the likely 20,000 total users on the instance at this point. There are a few problematic repositories that seem especially slow. One repository was shrunk from 70GB as a Subversion repository to 7GB as a Git repository after some cleanup. However, this repository is still taking very long to clone and for other simple Git operations.
  • Customer requests:

    • 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.

      I would say there are several ways to approach this problem.

      First of all it would be great to understand what kind of data customer is storing in the repository: plain text files, binary or some other assets or artifacts. Then knowing how many files are there and what kind of file system is being used on the machines which are cloning and performing operations agains git repository. It is very important to understand where bottleneck is.

      If cloning a repository takes too long I would check performance statistics of GitHub Enterprise server. Maybe there is high CPU load or something is not good with disk or network I/O.

      I would try to investigate mirroring, clustering, geo-based sharding options if this is possible with GitHub Enterprise.

      Maybe there is also a way to speed it up on work-station side by using SSDs, avoiding doing git operations on network mounted volumes (NFS).

      Also large repository potentially could be split in several smaller repositories and they could be "included" in to the main repository as git submodules.

      And last but not least build-in means could be used to clean up git repository (git gc), reduce history if that is an option and potentially better usage of blob/asset management could be introduced either by adding additional tools or by using build it tools (git objects).

      As for the time frame I think research and doing proof of concept could be done in copy of that repository and once we will be able to prove our assumptions we could develop migration plan for the customer.

    • Acme wants us to help them test GitHub Enterprise perfomance on a test machine for 20,000 users (their anticipated peak). They don't want any surprises when they reach that user count. They have asked you to make them a testing suite to mimic the type of load they will see to be assured GitHub Enterprise can handle the load.

      First of all before writing any tools I would double check are there any existing tools within GitHub which could showcase such things.

      Also it is important to know where and how customer plans to deploy GitHub Enterprise. So this way I could do the same to deploy it for the showcase and recommend them what kind of specs and configs they could use in order to achieve desired results.

      Then I would like to understand typical behavior of their user who would interact with GitHub Enterprise to better understand how stress test could look like.

      Test suite could contain basic git operations (i.e. clone, add/push, pull) and some GitHub Ent. operations like search, creating issues, creating gists, checking activity, creating/merging pull requests, editing wiki page, etc. These operations will be performed using GitHub Enterprise API.

      And last but not least I would provide them dockerized tool for testing so they have simple way to execute it. I would pick Go to write the tool because it is very performant.

    • 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.

      Using one standardized solution would help customer to improve in many areas including but not limiting to:

      • Using well known solution could help them to onboard new team members and reduce learning curve as well as using familiar UI could improve their user experience.
      • Using GitHub Enterprise will help them to have one single source of truth and single sign-on. There is no need to check multiple different source code hostings and services with potentially different credentials in order to find necessary information.
      • Using same tool could help them out to unify their CI/CD pipeline as well as enable code sharing.
      • Social aspects of using GitHub Enterprise will enable customer to be always up to date with the Activity Stream so people can keep an eye on whats going on and potentially contribute to many different projects way easier than before.
      • Maintenance of one solution is easier than maintenance of many different solutions and services.
      • GitHub Enterpise could provide better stability and scallability.
      • Old version countrol systems could redirect to GitHub Enterpise after successful code migration.

Prompt #2

  • Company: Dunder Mifflin Technologies
  • Version Control platform(s): Dunder Mifflin has a legacy technology stack. They are trying to reinvent themselves. They currently use Gerrit, out-of-the-box Git, Subversion, and Team Foundation Server.
  • Customer requests:

    • "Help us modernize our software delivery and become a technology company."

      I would suggest them to switch their stack to modern up-to-date stack for Git - GitHub Enterprise. It will improve stability, maintenability and performance. Also it will unify their version control systems as well as provide code review tools and CI/CD integration. And last but not least it will allow signle sign-on, 2FA and central user management.

      Of cource I would need to learn more about their requirements, scale, expectations and technical stack to provide better solution.

    • "Helps us learn to deliver software more often to tighten the feedback loop on features and new direction. Developers that are on our team want to ship software faster. We are not really sure how we can do that with our outdated testing and infrastructure. Can you outline some steps for us to cut our release times in half (from every 2 months) in the next year?"

      For that I would need to learn about their current SDLC, tech stack, planning process, software development methodologies, product, customer base and profile to understand problem statement better.

      For example:

      • Are they using Agile or Scrum or Waterfall? Or maybe something else?
      • Do they have dedicated QA team or do they rely on developers to test things?
      • What is their planning process?
      • What kind of enviroments they have (production, staging, integration, testing, etc)?
      • What is their test coverage? Do they write test for automation and what kind of tests?
      • Do they practice continious integration and delivery?
      • Do they have split (A/B) testing environment?
      • What kind of feedback they are looking for?

      As first steps I would suggest:

      • To increase code coverage.
      • Integrate CI/CD system which would continiously run tests and deploy to integration/staging environment on every merge from the feature branch to master (after tests are green and code review was done and merge request was approved and merged).
      • Reduce feature size, make it more atomic and "packaged as deliverable".
      • Work on code modularity to reduce dependencies.
      • Shorten development cycle. I.e. use kanban and work closer with stakeholders: PO, design team, QA, etc.

    • "We really need to make the cultural shift with our employees as much as the technical changes. Especially with some of our tenured employees who built the original tech stacks."

      I would suggest to collect feedback from employees about their painpoints and challenges. Then I would try to come up with showcases about how those paintpoints could be removed and challenges solved.

      Also I would include information about how modern tech stack looks like, what kind of benefits it can bring and how employees as well as company can benefit from it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment