Skip to content

Instantly share code, notes, and snippets.

@jmaryland

jmaryland/TechChallenge.md

Last active August 30, 2020 18: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 jmaryland/a3bcced8d02b49989933ad61c5ab7940 to your computer and use it in GitHub Desktop.
Save jmaryland/a3bcced8d02b49989933ad61c5ab7940 to your computer and use it in GitHub Desktop.
Download ZIP
JM_Tech
Raw
TechChallenge.md

PART 1

Prompt one

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.

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.

Challenge

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

Approach

We will look to shrink down a long running repository without having to recreate it. Using BFG Repo-Cleaner/git-filter-branch

Preparations

  • Clean up your branches (and tags)
  • Take care of open pull requests
  • Test run - As the changes we’re going to do can’t easily be reverted, it may be a good idea to test this on a copy of the repository and just do the changes in one single run on the live repository at a later point.

Plan Of Action & Next Steps

  • Clone the bare repository
  • Clone the full repository
  • Step 1: Removing files still present ( clone copy )
  • Step 2: Removing deleted files ( clone copy )
  • Step 3: Apply these changes to your actual repository. While doing this on a copy we saved all the commands we ran into a single script so we can now run all this on the actual repository once we took care of all the open pull requests.
  • Step 4: Place the binary files that are still required somewhere else using git lfs.

References

Consolidate instances

Challenge

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

Preparations / Plan Of Attack

  • Setup mirror repositories that are keep in sync in the background
  • A migration from a GitHub Enterprise Server instance to another GitHub Enterprise Server instance. You can migrate any number of repositories owned by any user or organization on the instance. Before performing a migration, you must have site administrator access to both instances.
  • Generate a list of migration conflicts
  • Review & resolve migration conflicts

Migrate SVN repo

Challenge

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

Recommendation is to approach this in phases, lift and shift then migration to Pull-Request

  • Step 1: Backup your old Repository
  • Step 2: Create the new Repository
  • Step 3: Import your old repository into the new one Note: ```What if someone committed a new revision to the old server during installation?

You can easily import the new revision, by creating an incremental dump on the old server```

References

Prompt two

Company: Dunder Mifflin Technologies

Version control platform(s): They currently use Gerrit, out-of-the-box Git, Subversion, and Team Foundation Server.

Customer requests

Modernize our practices

Challenge

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

Preparations / Discussion Points

  • Setup a time to do a assesment of the current env.
  • Identify what is working well and what is not
  • Return with a POC that mimics customer env & the new reference archetecture they'd trnsition to. Detail everything in a roadmap with highlighted milestones through completion.

Release More Often

Challenge

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

Plan Of Attack

  • Identify monolithic repositories/processes that can be divided to improve agility
  • Most successful apps release 1-4 updates a month.
  • Update frequency will depend on user feedback, data, and team size.
  • Most feature updates should be scoped to be no more than two weeks.
  • Balance faster bug fixing updates with longer feature releases.
  • Plan 2-4 updates in advance but keep attuned to market demands.

Commit/merge/deploy permissions

Challenge

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

Preparations

  • Review Gerrit setup
  • Github features that can be used to address company requirements and evolution
    • Access Permissions
    • Webhooks
    • Integrations

References

PART 2

For this section of the screener, we would like to gain insight into your ability to learn technical topics. Customers will frequently ask for assistance on projects. These requests will require you to learn new topics. This exercise will hopefully give us insight into your approach and aptitude in meeting these customers' needs.

GitHub API Challenge

GitHub has a powerful API that enables developers to easily access GitHub data. Companies often ask us to craft solutions to their specific problems. A common request we receive is for branches to be automatically protected upon creation.

Please create a simple web service that listens for organization events to know when a repository has been created. When the repository is created please automate the protection of the master branch. Notify yourself with an @mention in an issue within the repository that outlines the protections that were added.

Solution

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