It’s 2022: You’re good at your job, you’re maintaining modern systems, now you want to level up your team based on a solid foundation of their collective expertise. You want to standardize and centralize process documentation and make execution as easy and effective as possible so that everything runs smoothly, every time.

Mattermost Playbooks help software engineering teams orchestrate their work across all tools and teams to plan projects and hit milestones by uniting your tech stack through a single point of collaboration. We want to see how our community is leveraging Playbooks in their own tech stack and share your creations with everyone so the whole community benefits. We’re doing this by launching a new effort to commission original blog articles that show Playbooks in action.

The goal of Mattermost Playbooks is to help teams consistently orchestrate any and all recurring workflows. A Playbook is a prescribed, repeatable process that a team has agreed on and formalized as a collaborative checklist saved on their Mattermost server. We at Mattermost use Playbooks for incident collaboration, customer onboarding, and product releases, along with many other complex processes.

Mattermost v6.3 (Extended Support Release) is generally available today and includes the following new features (see changelog for more details).

In this post, we’ll examine a way to create a Workplace Wellness program that can be used within Mattermost. This program consists of four distinct apps which are meant to help companies that are embracing a remote work culture.

For all intents and purposes, 2021 was a jam-packed year for Mattermost, our contributors, employees, customers, and extended community. We broke through the muck that was a challenging 2020, and shared in celebration as we delivered the first open source collaboration platform to feature messaging, project and workflow management all in one convenient suite. But 2021 was about more than just our major platform 6.0 announcement in October.

The majority of engineers know that a minor misconfiguration might lead to some big troubles. Usually, we tend to forget the importance of that tense when we are configuring a new tool or a new service, as our focus is initially to make the tool functional and to evaluate if it fits our needs. Mattermost Cloud hosts thousands of workspaces which each one needs to have a different database backend, as in Mattermost we think that isolation is one very important aspect in our security guidelines.

The database/sql package in the Go standard library maintains a pool of connections so that all queries going through a single *sql.DB instance will reuse the same pool. This is great because you get a connection pool out of the box. But what if you need to share the same connection pool across processes? How do you use the same API in different processes but still reuse the same pool?

Ask any software engineer about the best way to do something and they’ll likely tell you “it depends.” Every project and team works differently and has specific concerns, requirements, and opinions, adding complexity on top of the technical and operational complexity of software development. The challenge lies in managing the work and emergent complexity while staying abreast of industry best practices in a way that fits our teams’ particular processes and environments.