Mattermost v6.7 is generally available today and includes the following new features (see changelog for more details).
Ask any engineer what they’d like to eliminate from their daily to-do list, and the answer will almost certainly be some version of reducing toil. Engineering organizations can burn hours and hours of work time on repetitive, manual tasks that reduce bandwidth for high-impact projects. That being the case, it’s no surprise that reducing toil helps your team work more productively and experience better job satisfaction in the long run.
Bringing the best software solutions to market as quickly as possible requires using automation to facilitate repetitive tasks (e.g., testing) so you can spend more time writing high-quality code. This is one of the main reasons why today’s top-performing dev teams build continuous integration (CI) and continuous delivery or continuous deployment (CD) pipelines, which enable them to ship new releases faster.
Most products that run as Software-as-a-Service (SaaS) are built to be multi-tenant, meaning that a single instance or deployment is meant to be used by multiple organizations. There’s a good reason for this: it’s generally easier to scale and operate multi-tenant applications. But in this new age of containers, orchestration, infrastructure-as-code, and Kubernetes, where it’s cheaper, faster, and simpler to deploy a new instance of an application, that may no longer be the case.
Oftentimes, people starting their journey in the field of software development don’t understand the importance of testing, including Golang app testing, until late in their careers. It’s essential to think about testing as an integral part of the software development lifecycle (SDLC) not only in theory but in practice, too. When building cutting-edge software, you need to make sure that the version being upgraded is error-free and that almost all of the failure cases have been considered.
When it comes to learning from incidents, your tools should adapt to the way your organization works. Many of you conduct your retrospectives in rich-text document editing tools, like Google Docs. That’s why we’ve introduced the option to export your retrospectives to Google Docs. Retrospective export to Google Docs can be automated as part of your incident management process with a Runbook step.