Skip to main content

VOL. V

David Bonhagen
David Bonhagen
Deployment, Patterns, Best practices

FULLHAUS DEV DUNGEON

  • Best Practices: Pull Requests
  • Discussion: who deploys the PR?
  • Design pattern of the month: the Singleton
  • Dungeon Pick

Best practices for pull requests​

You can follow best practices to improve the consistency and quality of pull requests and pull request reviews.

Write small PRs​

Aim to create small, focused pull requests that fulfill a single purpose. Smaller pull requests are easier and faster to review and merge, leave less room to introduce bugs, and provide a clearer history of changes.

Review your own pull request first​

Review, build, and test your own pull request before submitting it. This will allow you to catch errors or typos that you may have missed, before others start reviewing.

Provide context and guidance​

Write clear titles and descriptions for your pull requests so that reviewers can quickly understand what the pull request does. In the pull request body, include:

  • The purpose of the pull request
  • An overview of what changed
  • Links to any additional context such as tracking issues or previous conversations

To help reviewers, share the type of feedback you need. For example, do you need a quick look or a deeper critique?

If your pull request consists of changes to multiple files, provide guidance to reviewers about the order in which to review the files. Recommend where to start and how to proceed with the review.

Conventions for naming​

The name of your pull request should be equal to the commit message for the final merge of the PR.

feat(corporate): add template for product header (#197)

Therefore, the title must be lowercase, it should follow our commit message conventions, and it should reference the issue that it resolves in the end.

Outlook​

We might try PR / Issue templates on some projects and recap the results in the next Dev Dungeon. Besides that we should also think about possible solutions to rebase merges (performed on GitHub) as those drop the commit signing.

Sources:​

Let's discuss deployment​

PR is approved, lead dev & account manager are happy, life is good.

The problem?​

  • It might happen, that merged code doesn't get deployed. That should not be a problem!
  • But reality can be a cold, dark, cruel place, where code gets deployed per sftp or databases change.
  • And suddenly tested code might not be tested anymore, but the account manager is breathing down your neck.

Would you deploy 10 commits from your colleagues to production without testing it?

How do you feel about deployments on friday?

Let's discuss​

  • How can we avoid situations like this?
  • Do we need "main maintainers" for every repo / project?
  • Should we talk about release cycles? E.g. deployment every two weeks?
  • Should we make no deployment on friday an official rule?

Discussion results​

  • We might appoint two "lead devs" / "main maintainers" for each project
  • Release cycles do not align with our structures
  • No deployment on friday is an official rule (with exceptions e.g. hotfixes)

The Singleton Pattern​

Singletons are classes which can be instantiated once, and can be accessed globally. This single instance can be shared throughout our application, which makes Singletons great for managing global state in an application.

The following is an example for the incorrect implementation of the singleton pattern:

let counter = 0;

class Counter {
  getInstance() {
    return this;
  }

  getCount() {
    return counter;
  }

  increment() {
    return ++counter;
  }

  decrement() {
    return --counter;
  }
}

Why is it incorrect? The problem is, if you would compare two freshly created instances from the code snippet, they would not be equal.

const counter1 = new Counter();
const counter2 = new Counter();

console.log(counter1.getInstance() === counter2.getInstance()); // false
warning

Singletons are classes which can be instantiated once, and can be accessed globally.

So we need a check in the constructor of the class, if the instance was already created:

let instance;
let counter = 0;

class Counter {
  constructor() {
    if (instance) {
      throw new Error("You can only create one instance!");
    }
    instance = this;
  }

...
}

const counter1 = new Counter();
const counter2 = new Counter();
// Error: You can only create one instance!

As this was only a very small look at the design pattern, for a deeper dive into patterns have a look at the source here: https://www.patterns.dev/vanilla/singleton-pattern

Dungeon Pick​

TL;DR: WordPress is deconstructing itself right now over private equity and it is painful to watch. Thank god for TYPO3 and hopefully open source will persist against investors in the long run.