Skip to main content
This document details the process common to almost every project.

​
Steps

The general process for development is:
1

Determine MVP for the issue

Before diving into a task, ensure that the issue is distilled down to its minimum viable product (MVP). Split it into multiple, smaller issues. This practice aids in isolating specific work segments and facilitates more effective tracking for project managers.Issues should be outlined with clear, concise descriptions of how to address them. Ambiguous or vague descriptions can lead to uncertainty about when an issue is resolved and may pose challenges for others who wish to contribute to the project.When in doubt, ask for clarification. It’s better to ask for clarification than to spend hours working on something unnecessary.
2

Take the issue

When tackling an issue, it’s important to ensure that your work doesn’t overlap with what’s already being done. This is usually managed by assigning the issue to yourself. In most cases, tickets will be pre-assigned to you, but if that’s not the case, feel free to take the initiative and assign the issue to yourself.
3

Write the code!

Having covered the preliminary steps, you’re ready to dive into the work.This work should be carried out on a dedicated branch. We follow the naming pattern {jira_issue_key}-{name_of_feature} (for example, TKSD-10142-add-yoast-plugin). This naming convention integrates seamlessly with our Jira Cloud instance, facilitating effective tracking and making it simpler to locate branches associated with specific issues.
4

Push early, push often

As soon as your code reaches a usable state, commit the changes. This practice aids in monitoring the issue’s progress more effectively and prevents scenarios where extended periods pass without visible progress. Additionally, it opens the door for team members to observe your work, providing opportunities to correct any misconceptions early on, which can save hours of effort. If automated testing is configured for the repository, pushing your code will also trigger these tests.You don’t need to push every commit, but be sensible.
5

File a PR early

Once you’ve pushed your code for the first time, creating a pull request (PR) is important to ensure your work is adequately tracked. Branches without associated PRs can easily get lost among others.In your pull request, include the Jira issue key in the title. Additionally, it’s helpful to briefly describe how you tackled the issue, offering valuable context for the PR.Most projects at Trew Knowledge come with a PR template. It’s important to fill this out as thoroughly as possible. This step gives reviewers a clear understanding of the PR’s context and streamlines the review process.
6

Iterate, complete, and submit for review

Continue your work, and when it’s complete, submit the pull request (PR) for review. This is usually indicated by applying a “Needs Review” label to the PR.Additionally, you’ll need to identify a reviewer for your PR. The appropriate reviewer can vary depending on the project and the specifics of the PR. For detailed guidance on selecting a reviewer, refer to the reviews guide.
7

Merge and ship!

The reviewer of a pull request usually handles merging the branch. The branch should also be deleted via GitHub’s UI after merging.

​
Deployable Branches

Typically, when branches like main, staging or develop receive a new commit, a CI workflow will be triggered to deploy the site. This is usually done with GitHub Actions or CircleCI on WP VIP projects.

​
Main Branch

The main branch of the repository should be deployable at any time. Rollbacks are handled by reverting main then redeploying. This means that features should only be merged into main when they’re ready to be deployed. Anything in main must go through code review before merging, and this can be enforced via the GitHub repository settings.

​
Staging Branch

This branch, sometimes called preprod, is meant to mirror the production environment. It is used for QA and testing and is deployed to a staging environment. The content from production is synced down from production to the staging environment regularly to ensure parity.

​
Develop Branch

This branch is sometimes used and deploys to a development environment. This is used to test features when we can’t test them locally.

​
Project-specific Main Branch

Some projects are part of a larger network of sites. The way we separate things so that new development does not impact existing or parallel work is by using a project-specific main branch. This branch is usually named after the project, e.g. projectcode-main. This branch is then deployed to a development or staging environment for testing and is merged into production when ready.

​
Features in Isolation

Given our asynchronous work environment, it’s crucial for everyone to maintain momentum without waiting on others. To facilitate a smooth development process, we create branches for new features or bug fixes. Once these changes are deemed ready, they move into the review phase and are subsequently merged. Each branch should be dedicated to resolving a single issue, aiming for its closure. In line with agile practices, issues ought to be broken down as much as possible, meaning each branch represents a single, focused change to resolve the issue at hand. Ideally, these features should operate independently, enabling developers to pick up an issue and progress without impediments. Nevertheless, it’s recognized that not all features can stand alone; some branches might lay the groundwork necessary for subsequent features.

​
Incremental Improvement

At Trew Knowledge, we embrace the principle of launching features in their simplest form and iterating on them over time. The essence of the agile framework is its commitment to continuous, incremental enhancements. By adopting this methodology, we introduce new features as soon as they’re functional, albeit basic, and then progressively refine them. This approach not only accelerates the development cycle but also facilitates collaborative efforts. With the foundational elements of a feature in place, our developers can work simultaneously on expanding and improving different facets of it. This collaborative, iterative process is especially beneficial for our team, which operates across different time zones globally, ensuring that work progresses efficiently and asynchronously.