If you're a developer, there's a good chance you're familiar with Pull Requests. They are a great way to contribute code to a project, or manage the development of independent features for a team. However, there is so much more you can do with them. We've listed the top tips here.
You might already be deploying your application through GitHub Actions or some other CI/CD pipeline. That's great! It's probably also running your tests and making sure your code compiles.
However, did you know that there are services that can also (in addition to your CI/CD pipeline) provision a temporary test environment for every pull request you open, which only lives as long as the pull request is open?
Well, you can, and it's a great way to help test the pull requests of other team members.
Without an on-demand temporary preview environment, your flow might look something like this:
- You deploy a pull request to some shared test environment.
- You have to make sure no one else is using the environment.
- If other people are currently using it, you're out of luck, and have to spend time testing the branch on your own machine.
- Once deployed, you test the features described in the pull request.
- When you're done testing, you inform everyone that the test environment is ready again.
Now, here's how that flow typically looks with an on-demand temporary preview environment:
- You go to the pull request.
- A test environment already exists for that pull request, and the URL to the environment has already been posted as a comment.
- You navigate to the given URL, and test in the cloud.
- When you're done testing, you merge the pull request, and the environment is destroyed again.
Let's take a look at the different options out there.
- More info: dogger.io
- Open source: Yes
- Demo: Portainer's open Pull Requests on GitHub
- Prerequisites: Your app must be able to run in Docker.
Pull Dog has a free-forever tier available for smaller projects.
If 4GB of RAM is not enough or you'd like to have many concurrent test environments running, there's a priced plan available starting at $14/month for unlimited repositories.
- Alive and updated regularly, as seen on its GitHub Insights page.
- Fully managed. No setup required except installing a GitHub app, which takes 37 seconds (we timed it!).
- Docker-based. If your application runs in Docker, it runs with Pull Dog as well. You can point it to a custom
docker-compose.ymlfile if you wish.
- Integrates well with any build system (or no build system at all for that matter). Is your build server already building your Docker images? No problem.
- Fully transparent. From a public roadmap to an open-source codebase.
- Only currently supports applications specified using a Docker Compose YML file (#630).
- Does not currently support a custom bring-your-own-server kind of infrastructure, and currently hosts everything on AWS Lightsail (#543).
- More? Leave feedback.
If you're working in a larger team, there may constantly be a lot of pull requests open, pending review.
Everyone might be busy working on their own features, and perhaps you've tried requesting a review from someone, and them forgetting it.
You don't want to personally remind them all the time since that might seem annoying, but you also really would like your pull request merged.
- More info: docs.github.com
- Open source: No
- Prerequisites: Requires a team or organization on GitHub
GitHub acquired Pull Panda (which happened to build Pull Reminders) to bring this directly into GitHub itself.
You can specify specific criteria that should be met for a notification to arrive (for instance, labels, specific text in the title of the pull request, pull request age, etc), and it doesn't tend to get spammy because it likes to summarize all reminders into one post, based on an interval.
- More info: eleminder.com
- Open source: No
- Prerequisites: GitHub or GitLab, and Slack.
While the GitHub Organization reminders give notifications for your whole team in a sumamry, Eleminder is tailored around individual reminders to individual people. That way, it is more direct. This however also means that there is more to set up.
This gets more important if you're maintaining an open-source project (although it generally applies to closed source as well). Once a secret leaks into your source code, it can get extremely difficult to remove again. Although GIT history can be altered and deleted, orphaned branches and old build logs might still contain the source code or leaked secret.
It is important to note that once a secret has leaked, it is already too late. However, it matters how quick you discover it before someone else does, so you can generate new secrets to use instead.
If you put your secrets inside GitHub's secret manager itself, it will try to mask them as well as possible from build logs and other places where it might leak.
However, it is a naive form of prevention which should not be used as the only form of prevention. For instance, GitHub will still happily log your secret if it contains linebreaks, just to name an example.
GitGuardian takes a different approach to secret prevention. Instead of trying to proactively prevent known secrets from leaking, it will reactively scan for potential secrets that have already leaked, and inform you as early as possible.
It does this by looking for patterns that are commonly used. For instance, Slack Webhook callback URLs, Amazon AWS Access Keys, etc. This can be more effective than scanning for a list of known secrets, because it will catch potential mistakes one of your developers might make.
GitGuardian can run for each of your pull requests, adding an additional safety measure.