A GitHub Pull Request Workflow

Nearly every dev and dev shop uses GitHub in some form or fashion. We have 23 repos on our public profile, and I won’t even tell you how many “aliases” we already use. Not to mention the small fact that everyone on our team uses GitHub independently. And everyone is trying to crack the code for a successful GitHub Pull Request workflow, hoping to have their contribution added to the main branch and become a contributing member.

However, the real question is how many of us actually contribute to the open source community regularly? Much less have a GitHub pull request accepted by the largest cloud provider in the world. The short answer is very few of us!

On the contrary, this article is about Manvendra, one of our amazing DevOps Engineers having his latest pull request merged by AWS for their product SAM, which is an acronym for Serverless Application Model.

The truth is that when used correctly, GitHub is a lot more than just a platform.

Whether you are coding solo or as a part of a large team, GitHub allows you to experiment with, and add your own genius towards the greater good.

As of June 2018, GitHub reports having over 28 million users. These users can be individuals or companies using individual profiles, like AWS (Amazon Web Services), who are very active on GitHub. And commonly push features and products out through the open source community under the profile awslabs.

It’s no surprise that here at SourceFuse, our AWS roots run deep. And while we are always monitoring, forking, and contributing to a bunch of open source projects in a myriad of environments, our affinity for AWS tools finds us frequently playing in their sandbox.

Recently, Manvendra one of our DevOps Engineers had his pull request merged into the latest production version of awslabs’ serverless-application-model or SAM.

“It has been extremely rewarding to have a GitHub pull request accepted. It is one of the most popular Open Source Platforms, especially on a project that we find value in every day and I plan on adding more of my learnings on to the platform.”

According to Manvendra, it took two days to come up with the code and build it. Then it took GitHub five days to review and post his addition. Where Brett Andrews, the AWS Engineering lead for SAM, actually pulled the request.

So, what exactly was the pull request contributed?

Manvendra contributed to the very popular repository from ‘awslabs’ for SAM or Serverless Application Model. According to Manvendra, the two main workflows he was dealing with when generating with the pull request merge strategies were:

1. A pull request from a forked repository
2. A pull request from a branch within a repository

Manvendra made an often overlooked, yet ‘incredibly’ valuable contribution onto the platform. Under AWS’ Serverless Application Model, he added one of the core chunks within the function module, a VersionDescription property on Serverless::Function.

The specific feature he contributed is called ‘Version Description’.

To visualize this, just think about Google Drive, the web application that some of us use on a daily basis.

If there are five people viewing the same document, and a change is made by person 1, then that change is updated in real-time to the other 4 viewers of the document. Hence, providing everyone with accurate and up to date changes. Allowing for instantaneous collaboration and confidence. That’s the concept behind ‘Version Description’.

Version Description provides all the other viewers of this repo with the latest merge commits and recent code.

Manvendra’s contribution made SAM more organized and easy to search. Now, every time the repository is updated, every person following the project can view the latest changes in real-time and ensure they are working locally with the most up to date code standards.

How did he come up with this pull request merge strategy?

Manvendra is fluent in Python and obsessed with organization and clean code. He took just two days to write the code and sent it off for review.

He built the entire code using Python 2.7 before submitting the pull request.

Here is his step-by-step procedure, using which he constructed the final code:

1. Setup the project by following the instructions mentioned in project repo under the contribution section.
2. Identify the Base Classes that make up the application and the execution flow between those classes.
3. Add the attribute for ‘VersionDescription’ in the SamResource Class.
4. Write Unit and End-To-End Tests for the changes that you need to perform in the repo.
5. Make a request to the repo owner through a pull request for the changes made.

Below are some pro-tips for getting your pull request merged.

Be very clear and precise, about which repository you want to add to. Rather than randomly browsing through GitHub and adding your pull request to any repository. Having a focused set of steps, tailored towards a specific repo is highly beneficial.

Follow this cadence:

1. Identify a bug or shortcoming and file it as an issue within that particular repo.
2. Ask the repo owner if they are, or know of anyone else already working on something similar to your newly recorded issue.
3. Always create a branch for your new code in the same repository and give it a short and easily understandable name.
4. Write a clean commit message with detailed information and use present imperative tense. For instance: ‘Adding a bug fix’.
5. Adhere to the repo author’s style decisions.
6. If you have not completed the pull request yet, make sure you add a [WIP] in the title.

For Manvendra, the review part of this pull request took 5 days with frequent and open lines of communication with the repo owner.

Awslabs follows a strict procedure for reviewing and validating the correctness of the added code. Currently, SAM is a priority, and they have specific initiatives in place aimed at improving their Serverless Application Model. So, they’re reviewing and accepting the best pull requests with top priority.

What Does AWS’s Serverless Application Model Do?

AWS’s SAM or Serverless Application Model, as the name suggests, works without the hassles of maintaining a server. It is an open source Framework used to build applications, without a server.

Copyright: https://goo.gl/images/Uks6Lh

Serverless refers to using triggers to manage the loading and implementation of an application dynamically allocating machine resources, rather than having to provision servers yourself.

Serverless benefits include:

• Allowing all your developers and/or coders to focus on the layout of the code and what function it is going to perform. Rather than waste time and resources on server compatibility.
• Ensure budget constraints are met. Because the efficiency of the code is clearly compatible with its running costs.
• Immediately realize all of the native benefits of event-driven applications.
• AWS SAM also provides integrations with the best development tools. Including AWS Serverless Application Repository, AWS Cloud9, AWS CodeBuild, AWS CodeDeploy, and AWS CodePipeline, just to name a few.

For more information on AWS SAM, visit: https://aws.amazon.com/serverless/sam/

Our take:

We are glad that our DevOps team is contributing to the Open Source Community regularly as we are always expanding our AWS horizon. These tight relationships allow us the ability to be on the cutting edge of tools our clients use and reap the benefits of on a daily basis. We also love congratulating and praising Manvendra on his successful addition, because it’s a pretty cool accomplishment personally and professionally!

If you’re interested in learning more from Manvendra or speaking with our DevOps and AWS teams, check out some of our training workshops — https://bit.ly/2XYy0zY. We regularly host AWS Cloud Practioner Traning Workshops and DevOps get-togethers.