Launch HN: Bitrise (YC W17) – Continuous Integration and Delivery for Mobile Apps
Bitrise is a Continuous Integration and Delivery platform specifically for mobile apps. We started working on Bitrise when we were running our dev agency, building apps for clients. It was frustrating to go through all the manual tasks when somebody needed a fresh build, or when all the bugs piled up before releases. We wanted to automate all the manual aspects of app development so we could get back to coding, because that’s what we loved to do.
We’ve started with iOS CI/CD, because that seemed to be the hardest and that’s what we had the most experience in. For starters we had to build up a scalable Mac infrastructure, since iOS apps can only be compiled on a Mac machine. That was tough.
We also wanted to make setting up and maintaining CI way easier, without scripting, but having the same level of customizability. We’ve come up with an easy workflow and step system, where steps are ready-made and reusable building blocks responsible for one task, like git cloning, deploying to HockeyApp, etc, and workflows are a succession of these steps. All of these steps are open source, and since we started the library grew to more than 100 integrations, around 30 added by the community (https://www.bitrise.io/integrations).
Tens of thousands of apps are being built on Bitrise including Foursquare, InVision, Pagerduty, Grindr. We are attracting so many apps because we are the most open platform in this space. In addition to our step library, we’ve open sourced our CLI, our webhook service and all of our build images, and we’re growing together with our awesome community.
We raised $200k in 2015 and became profitable last year. We feel extremely grateful and lucky to have gotten here, being a 7-people dev shop in Europe. Now we’re joining YC and we have big plans to take Bitrise to the next level!
We’d love to hear your feedback and are happy to answer any of your questions. Thanks!
59 comments
[ 1462 ms ] story [ 4105 ms ] threadGood job so far!
Our build machines are faster to use, too, because the most used VMs are pre-booted, which saves 1-2 minutes.
- Local CLI / runner: http://devcenter.bitrise.io/bitrise-cli/
- Trigger Map, to configure what to build when: http://devcenter.bitrise.io/webhooks/trigger-map/
- Linux/Android image available as an open Docker container: http://devcenter.bitrise.io/docker/run-your-build-locally-in...
- Open source, offline workflow editor (UI, beta): https://discuss.bitrise.io/t/offline-workflow-editor-workflo...
- (GitHub,) Bitbucket and GitLab (full API) support, and additional webhook support for Slack (trigger a build from Slack), visualstudio.com, gogs, deveo git repos through the open source Webhook processor (https://github.com/bitrise-io/bitrise-webhooks) - the last two were contributed by the community ;)
- It's the same runner which is used for running the builds on https://www.bitrise.io/
- You can run the same build config (YML) with it both on https://www.bitrise.io/ and on your Mac/Linux
- CLI [home page](https://www.bitrise.io/cli) | [docs](http://devcenter.bitrise.io/bitrise-cli/) | [GitHub](https://github.com/bitrise-io/bitrise)
(disclaimer: CTO here)
I run my current CI/CD pipeline through jenkins for Rails, and I would like to keep everything running through jenkins. Is there a way to do this currently with bitrise?
We are mobile focused at the moment, but a couple of our customers use it to build web projects and we are also building the Bitrise website on Bitrise.
Fastlane solves part of the problem, but I think you solve it all.
By the way, I've found this tweet: https://twitter.com/wercker/status/431757646333751296 Were a similar company explains that a service like this one is not allowed by Apple's EULA: http://store.apple.com/Catalog/US/Images/MacOSX.htm
Did you have any problem with Apple in the past?
We are using physical mac machines and according to their terms you can run as many virtual machines as many cores you have in the mac. However we have to get licenses for the VMs as well.
Keep Fucking Fire!!!
- Biggest difference is the reusable steps (e.g. add HockeyApp step, paste API token, good to go for deploy)
- Generally being more open - steps/integrations, stacks, CLI, webhook service, workflow editor are all open sourced
- Repository scanner - based on your configs you'll get a workflow to build, test and deploy your app in minutes
- You can download the bitrise.yml to run your workflows locally with our CLI: http://devcenter.bitrise.io/bitrise-cli/
- Trigger map, to configure what to build when: http://devcenter.bitrise.io/webhooks/trigger-map/
- (GitHub,) Bitbucket and GitLab (full API) support, and additional webhook support for Slack (trigger a build from Slack), visualstudio.com, gogs, deveo git repos through the open source Webhook processor (https://github.com/bitrise-io/bitrise-webhooks)
- Codesigndoc - an open source tool which, by running a line of command in your terminal exports all your necessary code signing files to upload to Bitrise
- We don't charge you for builds running over time limit
- You're able to use both Linux and macOS stacks on the same plan (either on free or paid)
The main differentiator might be that our platform is more open compared to Buddybuild's enclosed ecosystem approach. That means we allow much more customizability while having the same, fast initial project setup. Bitrise grows with the community, both by helping each other and developing extensions, like new steps/integrations and other tools.
We feel that Buddybuild is great for smaller projects, but Bitrise can provide more for more complex apps with more rigorous development cycles and needs, which is the feedback we get back from these type of companies as well.
We also have Xamarin support, which may or may not be interesting for you.
We certainly don't think of buddybuild as a closed ecosystem.
In fact, our users are able to customize buddybuild infinitely to meet the needs of their workflow (details can be found here: https://www.buddybuild.com/blog/customizing-the-build-proces...)
Further, while buddybuild is favored by thousands of because it can can auto-provision iOS devices for you on the fly. Meaning, you never have to deal with provisioning profiles and UDIDs ever again.
We also care deeply about making sure that teams can involve and engage their end users as part of the development process. One of the reasons we built buddybuild is because of the frustration sending builds to our users... AND then never hearing back from them. Phones are great devices for "consuming content", but it became obvious that the physical form factor of the device tends to result in infrequent feedback which was often ambiguous.
So, we build an SDK that gives you high quality and actionable bug reports from beta users. With a simple screenshot, testers can file bug reports that include graphically annotated screenshots, feedback notes and their device metadata.
We also have a feature called "Instant Replay", which lets you watch a video of the exact steps required to reproduce a crash. Instant Replay works in conjunction with our Crash Reporting solution to offer you both the exact lines of code that caused a crash as well as the exact sequence of events that lead up to it (https://www.buddybuild.com/blog/introducing-instant-replay)
Thousands of teams with fairly complex needs use buddybuild every single day. They teams like Slack, Meetup, FireFox, Wordpress and others..
You can read why they made the choice to use buddybuild here: http://www.buddybuild.com/customers
We have ionic & cordova preinstalled on the VMs ( https://discuss.bitrise.io/t/can-i-use-bitrise-to-automatica... ) and you can find some best tricks here: https://discuss.bitrise.io/t/best-practise-for-cordova-apps-...
And a blog post form on of our users: http://vgaidarji.me/blog/2016/02/27/how-to-build-cordova-bas...
We are also preparing the next additions for the scanner ( automatic project detection ) that will include cordova & ionic as well :)
It's awesome to see the mobile developer tools ecosystem as a whole expanding.
It wasn't too long ago that mobile teams had to use web CI products, awkwardly repurposed to build & deploy their iOS and Android apps - imposing on them a huge maintenance burden and slowing down the development of their apps.
Great tools help build great products, and the future for mobile development tools is very bright today.
- No need to worry about tooling maintenance anymore. Best example is when a new Xcode version is released, usually lots of things break. We test these out quickly and release the new version in a way that won't give you headache.
- You have the same kind of control over your build environment, but an easier time with project setup with our scanner and reusable steps. This means, you can do scripting, but you don't have to.
- Team and organization management features
- You don't lose the advantages of open source
- You get awesome tech support along with a very helpful community
- You get a much more intuitive and nicer UI/UX
We hear from a lot of our users coming from Jenkins how it took up more time for them to maintain the build machines than it actaully saved, while not always delivering proper build results, lacking the always clean kickoff state.