Introduction: What is a Slack App

A Slack App (or a Bot) is essentially an integration that extends the capabilities of the Slack platform, allowing users to interact with external services and applications without leaving the Slack environment. These apps can be built to automate tasks, provide notifications, gather data, or offer a wide range of functionalities tailored to the specific needs of a team or organization.

‍

Importance of Team Collaboration in Slack App Development

Collaboration is fundamental to Engineering development. While teams can start off small - it is common for product engineering teams to scale to thousands of developers. A Slack App is common for many products today - and many developers may be participating in developing features for a single Slack App within a company. For example - at ClearFeed - we have a team of 10+ developers working on our Slack app that helps Support teams keep track of requests on Slack.

Unfortunately - the default Slack App environment provided by Slack is not robust enough to support the general development process where you need to have many versions of the App running for individualized testing.

This is where Slack Developer Sandboxes come in. Whether you're a seasoned developer or just starting with Slack App development, this blog will guide you through the essential steps, tools, and considerations for building powerful Slack Apps with your team by using Slack Developer Sandboxes.

‍

Unpacking the Basics: Creating a Slack App

Navigating the current flow of Slack app development is vital before delving into its challenges. Registration on api.slack.com/apps initiates the process, providing options to set up bots based on specific requirements. While the setup intricacies lie beyond the scope of this blog, understanding this foundational flow is essential.

For individual developers or small teams with singular environments, the journey seems straightforward at this point - register, install, and test. However, the complexity amplifies when operating with larger teams, where each developer requires distinct testing environments.

‍

Testing Slack Apps in Large Dev Teams

Imagine a scenario where there is a team of 10 skilled engineers working in one Slack App. Each developer wants to test the app from their own code (running in their own, exclusive, development environment). 

What are some common requirements for developer Testing? We have listed some of the common ones below:

• Requirement 1 - Creating Test Slack Users: One of the common needs of every Slack App developer is to have some test users in Slack. Consider a typical application, with some users on Slack:
  - Roles on Slack can be - Channel manager, workspace owner, external user, guest user, etc.
  - Roles in the Product can be Admin, Owner and others (like Agents in ClearFeed)..
  
  It is difficult to act in these roles with a single user, we need to have multiple users - each of them dedicated to specific roles. So in a typical developer setup for a Slack App - we have to set up multiple users. We need to create Gmail/Microsoft.. accounts for each of these users and register them on the Slack workspace. This is a lot of work.

• Requirement 2 - Slack events and interactions need to be routed to Developer Sandbox: Each developer sandbox must be able to receive interactions, events, and slash commands from Slack and respond to them.
  
  
• Requirement 3 - Easy to differentiate within Slack: It should be easy to differentiate between the different developer Sandbox interactions from within Slack.
  
  
• Requirement 4 - Easy to administer separately: Each developer may want to change the Slack App setup - like the scopes or the supported shortcuts etc. for their own sandbox only. 

‍

Possible Test Setups

Given the requirements above - how many Slack Apps to setup in such a situation. One can either setup Shared Slack Apps or a Dedicated Slack App per Developer for Testing. We look at the pros and cons of these approaches in the following sections.

Alternative 1: Shared Slack Apps

Creating one or a few Slack Apps - and sharing them across developers sounds like a good simplification.

Pros

It allows a small number of Apps over which developers, QA and Product Managers can collaborate over (ie. Requirement #3 is fulfilled). The Test Users (Requirement #1) can be created just once. It also reduces the burden of creating many apps.

Cons

However - a basic question that arises is how multiple developers can each test their code (running in their Sandbox) against the same Slack App in the same Workspace? There are two fundamental issues here:

• (Requirement #2) Slack bots operate on the principles of interactions, events, and slash commands, all directed towards a single endpoint. How will each developer sandbox have it’s own endpoint?
• (Requirement #4) The scopes of the app are common and shared across all the developers. This means if a developer needs to introduce a new scope for developing a feature, they typically register this scope in the shared app - and this affects all developers.

There is no good solution for Requirement #4 in this test setup - some teams maybe able to live with this. However, a solution for Requirement #2 is listed below.

Proxies: A solution for sharing Slack Apps across Developers

The first problem can addressed using the concept of a proxy (like ngrok). The ingress URL of this proxy is provided to Slack, and egress URLs are then directed to different developer sandboxes. This setup ensures that all interactions, events, and slash commands are broadcast to all developer sandboxes.

Problem solved? Not quite. Consider a specific use case involving button interactions. 

• When a user clicks a button, the application is designed to send a message to the user upon receiving this button interaction event. 
• With a proxy - each developer sandbox receives this interaction event.
• Consequently, the user receives several messages equal to the number of such sandboxes. 

The challenge here lies in the shared nature of this interaction event across all the developer sandboxes. While our development team initially used shared environments with proxies - we could not make it scale because of this interference and gave up on it eventually.

‍

Alternative 2: Dedicated Slack App per Developer

Pros

In this case - Requirement #2 (each developer sandbox getting interaction and other events from Slack) and Requirement #4 (each developer being able to administer the Slack App without interfering with others) are fulfilled automatically.

Cons

Unfortunately - some of the problems nicely solved using shared Slack Apps have come back:

• (Requirement #3) Differentiating between so many different Apps within a single workspace and using them is problematic.
• (Requirement #1) Creating Test Users again and again is also very tedious and problematic.

A Free Slack Workspace for each Developer?

An obvious idea here is for each developer to create a free Slack workspace just for their own testing. That way they do not see and interfere with each other’s Apps. While this may work for some projects - there are some issues with this approach - primarily that the free version of Slack comes with limitations. Example limitations that can be important for developers.

• Workflows are not available in the free version.
• Slack Connect is not available in the free version.
• The number of Apps that can be installed is limited to 10 - and this can impact integration testing.

‍

Introducing Slack Developer Sandbox

So if neither a shared Slack workspace, nor free Slack workspaces are the answer - so what is? This is where Slack's Developer Sandbox comes into play. Designed to assist developers in building Slack applications without causing disruptions in production instances, the Developer Sandbox offers a controlled environment for testing. In the following sections, we outline a series of steps for setting up and leveraging Slack Developer Sandboxes.

Step 1: Getting the Workspace Ready

To acquire your own Slack Developer Sandbox, simply register here. After submitting your request, approval may take a couple of days, granting you access to the sandbox environment. For detailed instructions on setting up the sandbox, refer to Slack's documentation available here.

Once your sandbox is ready, you can create numerous workspaces, Ie. - we can now create one workspace per developer within the Slack Developer Sandbox  Inviting your teammates to this sandbox ensures that each team member possesses their own dedicated workspace for comprehensive testing and development.

Each such workspace can be equipped with sample users. Leverage these sample users to simulate various roles when interacting with the bot. 

Step 2: Getting the Bots Ready

1. Begin by registering a bot on Slack using https://api.slack.com/apps/ and configuring it to align with your specific use case. Consider this bot as your primary source, usable in any environment.
2. Replicating the bot becomes a seamless process if you possess its app manifest. Retrieve the app manifest from the app configuration page.
3. Share the configuration page with your teammates, and ask them to create their own bots using the provided manifest file. Refer this document for guidance. Note: Ensure the interaction, events, and slash command URLs are updated according to each user's local setup.
4. Install these bots in their respective workspaces on Slack. Repeat these steps for other environments such as staging and testing. Pro tip: Differentiate between environments by updating slash commands and the bot's name. For instance, transform a production slash command like /task-maker register into /staging-task-maker register for clarity.

Step 3: Managing the Bots

Bot configurations are subject to change, whether it involves adding a new scope or introducing a new workflow step. Although such updates may be infrequent, it's crucial to establish a reliable process to manage them. Here's a refined approach:

1. Centralized Versioning: Maintain the app manifest in a centralized versioning system like GitHub or GitLab. With each update to the manifest, create a new commit in the repository. This not only provides version control but also offers a clear record of changes over time.‍
2. Automation Script: Develop a script to effortlessly retrieve the app manifest from the repository and upload it to your bot. Each developer should have this script in their local environment, ensuring consistency. Alternatively, a centralized script can be employed to update all bots simultaneously, streamlining the process.‍
3. Utilize Slack's API: Use the apps.manifest.update API from Slack to upload the updated manifest to your Slack app. To access this API, utilize the "App configuration token," which can be generated here. This step ensures that the configurations present in the centralised repository are seamlessly integrated into all the replicated Slack apps.

By following these steps, we effectively solve the challenge of keeping bots in sync. It establishes an efficient process for managing updates and maintaining consistency across the development team.

‍

Conclusion

To sum up, creating collaborative Slack Apps involves overcoming challenges through structured processes, dedicated workspaces, and bot management. This empowers both seasoned and new developers to successfully build powerful and synchronized Slack Apps with their teams. At ClearFeed we have built a robust Slack App using these processes that allows Engineering, IT and Support teams to track requests on Slack - and we would love to hear from you if this seems interesting!