Breaking stuff in the production environment is one of the most common nightmares that software developers have, even those very experienced. Who hasn’t heard about (or witnessed…) an entire app being down or database lost because of one tiny mistake? Luckily, there are numerous ways to prevent it and we’re proud to announce that Forest Admin has recently added functionality that:
- significantly reduces the risk of breaking stuff, and
- makes the collaboration seamless and efficient, especially in teams of dozens of developers. Now, teams can maintain internal tools with much more confidence.
Let us introduce Development Workflows! 🎉
Introduction to Development Workflows in Forest Admin
Before we explain how Development Workflows are organized in Forest Admin, let us give you a brief introduction to the fundamental concepts behind them: version control and branches. Using version control systems such as Git forms an essential part of software development. Without them, even tiny changes, bug fixes, or working in a team on the same codebase, pose a risk of breaking the working product.
One of the most important concepts in version control is branches. In short, they make software development safe by allowing developers to keep different versions of code separated.
How are branches most commonly used?
- To introduce new features and experiment with them. It doesn’t matter whether it’s a tiny change or a brand new functionality - it’s always a good practice to create a separate branch for that and delete it once it’s deployed or decided not to.
- To fix bugs. Except for fixing tiny bugs, it is recommended to create a branch to make sure your fix doesn’t interfere with the working product and other dev’s work.
If you’re reading this post, you’re likely a Forest Admin user or you’re interested in developing an internal tool for your data, for example, an admin panel. It means you’re interested in building an application within the Forest Admin platform and you would expect a similar workflow to the one you know from Git or another version control system. We get it. Let’s have a look at how it works.
How are Forest Admin Development Workflows used in practice?
Development Workflows are relatively new at Forest Admin but some of our clients have already tested them heavily. To give you an example, developers from Qonto, the leading neobank for SMEs and freelancers, need to make sure their production environment is always safe and 100% operational. Qonto has built their internal applications using Forest Admin in order to track all the financial flows in their database, analyze the data, and take action towards fraud prevention. On top of that, Qonto is highly customer-centric and the company can’t risk any issues with accessing the product.
Before Development Workflows, each change (e.g. adding a custom action like refunding a customer) required creating a development environment, making the change, and deploying. Now, a developer creates a branch that inherits from the production environment, tests a feature, and if everything is fine, deploys it to production without the risk of breaking the product or interfering with another developer’s work. Let’s imagine that at the same time, his colleague is working on another custom action, for example, a smart form. She creates a branch and follows the same steps. Both work on the same product at the same time but each on their own branch. Here is what Maxime Durand, the Backend developer at Qonto, says about Development Workflows in Forest Admin:
Developing locally is a necessity for us developers. Before testing on a staging environment and then deploying in production, Forest offered us a complete development workflow tool that can be used directly from the CLI. Our productivity has increased significantly on a daily basis.
Another satisfied Forest Admin client from the financial services industry is Melio, a company with the mission to keep small businesses in business. In order to focus all their efforts and resources on their hypergrowth (in 2021, Melio raised $110M on a $1.3B valuation), Melio decided to build their internal tools with Forest Admin. Similarly to Qonto, it has been critical for Melio to make sure their back-office is fast, efficient, and always operational so that their finance and customer service teams are able to process tens of billions of dollars in transactions, from tens of thousands of users.
Melio’s Product Management team couldn’t stress more the importance of having a safe and operational production environment that can’t be broken by working on new features.
Are you ready to create your own Development Workflow?
To get started, you need to understand how development tools work in Forest Admin. You may know that your admin panel is composed of two parts: the frontend and the backend. The admin backend is a part of your codebase and you are free to use your favorite editing and versioning tools. Thanks to that, the data is only hosted on your end and the user browser, it never transits through our servers.
The admin frontend, on the other hand, is not a part of your codebase but it is managed on Forest Admin servers and you need our tools, such as the Layout Editor Mode to intuitively manage your layout (UI) and the Forest CLI to manage your layout versions. Development workflows are the newest addition to the frontend.
Here is how we recommend setting them up:
After installing the Forest CLI and your development environment (please find the detailed instructions in the Development Workflow documentation), it’s time to create a branch and develop your feature. As already mentioned, branches are essential in software development. They’re also critical in building internal applications in Forest Admin as you can’t version them the same way you version your backend in Git or another versioning tool. The reason is simple - your internal app’s frontend is saved on Forest Admin servers. You shouldn’t worry, though, as we created branches to make your codebase safe.
Basically, branches are versions (you can call them copies) of your origin environment, which is usually your production environment. In Forest Admin, you can also work on staging (remote) and of course, production environments. For example, if you want to experiment with a feature, make a branch on your development environment, test it, and then move or apply it to a remote environment, usually to production.
For step-by-step instructions on how to create branches, go to our documentation that covers using branches. Once you’re perfectly satisfied with the result, it’s time to try it on a remote server and deploy it to your origin environment. For further instruction, refer to the next part of the Development Workflows documentation.
- Thanks to Development Workflows, every team member can add functionalities without the risk of breaking the panel or interfering with other team members’ work.
- Your Forest Admin is composed of two parts: the frontend and the backend. The admin backend is a part of your codebase and you can use your own editing and versioning tools. The admin frontend, on the other hand, is not a part of your codebase but is managed on Forest Admin servers. That’s why it doesn’t offer full version control but you can take advantage of branches.
- Branches are perfect for bug fixes, experiments, and introducing new features - no matter how big or small.