Used by companies as diverse as NASA, Pinterest, and CitiBank, JetBrains takes the repetition out of a developer’s life through their range of developer tools which automate routine checks and corrections. JetBrains offers 21 different tools for developers and in the last couple of months have created snaps for around half of their portfolio. Aleksey Rostovskiy from JetBrains explains how they have been using snaps to date and their journey from discovery to over 60,000 installs since autumn this year.
Can you tell us about JetBrains as a company and the snaps published or in development?
JetBrains is a software development company that strives to make the strongest, most effective developer tools around. We deliver intelligent software solutions that make developers more productive by simplifying their challenging tasks, automating the routine, and helping them adopt the best development practices.
At JetBrains we have a number of tools for different programming languages and technologies: a set of IDEs, such as IntelliJ IDEA, PhpStorm, and PyCharm; .NET development tools: ReSharper, Rider, dotMemory, etc.; team development tools: TeamCity (CI solution), YouTrack (bug tracker), and Upsource (code review tool); and Kotlin, a JVM-based language originally developed at JetBrains. All our IDEs are cross-platform, and Linux users comprise a large part of our user base, which is why we’ve been looking to improve the installation and update experience for Linux users. Recently we adapted snap packages for almost all of our IDEs and published them in the snap store. Snaps for the rest of our IDEs are on their way.
We’re still evaluating how well snaps work for our users. Right now we’re promoting snaps as a suggested installation and update mechanism only for PyCharm (our Python IDE), while looking into how people use snaps for other products not being promoted.
What was the appeal of snaps that made you decide to invest in them?
There has always been a need for an automatic and convenient way to manage installations of our IDEs. We do 3 major releases per year for each of our IDEs, we release minor bug-fix updates quite often, and we run Early Access Programs for each of the IDEs in which we release a number of alpha and beta builds prior to the next official stable release. This way, our active users can put their hands on coming features and bugfixes earlier in the release cycle.
Many users have several IDEs installed on their machines, which means keeping track of updates can become a mess quickly. Many weren’t happy with plain tar.gz archives, so we decided to invest in a more standardised way of distributing our software. Snap packages seemed exactly what we need, and we’re happy that now our Ubuntu users can easily install an IDE from a desired channel and forget about updating the builds as the updates come in the background automatically.
How does building snaps compare to other forms of packaging you produce? How easy was it to integrate with your existing infrastructure and process?
It took some time to integrate snaps into our existing build processes. However, once we implemented building snap packages automatically on TeamCity (our CI server) for one of the IDEs, it wasn’t that hard to adopt the same process for other tools we have at JetBrains.
Image: PyCharm Professional
Do you currently use the snap store as a way of distributing your software?
The Snap store provides additional exposure to our tools for many of our existing and potential users. The decision to use it came quite naturally. We believe the store will be a major software discovery tool on Linux, so the more people find out about our tools naturally and install them more easily, the better for everybody.
If so, how do you see the store changing the way users find and install your software?
Searching for software on the snap store and in the Ubuntu software centre are the standard ways for many Linux users to discover and install software on their systems. Previously, our users could get installation artefacts only from our website. With snap packages, the new method is now recommended on our website and people can also discover our products organically in the snap store. The installation process with snaps is easy and straightforward, reaching a wider audience, which benefits us as developers and our users in many ways.
What are your expectations or already seen savings by using snaps instead of having to package for other distros?
Since implementing snap packages for our tools, we’ve been seeing continuous growth in their usage. So far we haven’t got any major complaints, which we think means people do like using snaps. We expect more and more people will use snaps in the future.
The only missing thing when shipping our tools with snap packages is that we require the “classic” confinement policy to make our tools work properly on Linux. This mode is available only on Ubuntu, but we’d like to expand snaps as a recommended installation method for other popular Linux distributions. We hope that the “classic” policy will become available for other distributions at some point.
What release channels (edge/beta/candidate/stable) in the store are you using or plan to use, if any?
During our release cycle we ship Early Access Preview, Public Preview, Release Candidate, and finally release builds, so our process matches snap channels pretty well. We put all Early Access builds into the edge channel, Public Previews into the beta channel, etc. We find snap channels are very flexible and satisfy all our needs.
How do you think packaging your software as a snap helps your users? Did you get any feedback from them?
The main advantage of using snap packages for our users is that they don’t have to care about updates, whether they’re participating in our Early Access Program or using officially released builds only. They just install tools from desired channels and the update process happens in the background, so they always stay on the latest version available.
Learn how the Ubuntu desktop operating system powers millions of PCs and laptops around the world.