HN user

viktorbenei

27 karma

CTO and Co-founder of Bitrise ( https://www.bitrise.io/ )

Posts9
Comments35
View on HN

Bitrise.io ! ;) (CTO here)

Added bonus: most of our tools are open source, e.g. you can use the same runner which we use to run the builds on our build VMs ( https://www.bitrise.io/cli ) to run the bitrise config/build anywhere the CLI can run. Happy to answer any questions!

Bitrise.io | Budapest (Hungary) | Full-time | Onsite

Bitrise is a Continuous Integration and Delivery platform focusing on mobile development. We help developers to automate their every-day tasks so they can go back to building great apps and have more time for their ideas. We'd like to create an ecosystem for software developers which they can use to build, test and distribute their apps in a way that it feels natural and fun. We take being open very seriously and we love to automate everything!

We'll soon update our jobs site ( https://www.bitrise.io/job ), looking for right now:

- Web Dev (both front & backend positions, Senior & Junior too)

- Tooling: work on our open source tools which make Bitrise awesome ( https://www.bitrise.io/cli )

- Developer Experience (DX) Engineer

- Infra Engineer

And a lot more. If you're interested in working for a YC company in Europe, feel free to ping us, there's always a place for great devs in our team ;)

Bitrise! Both the open source CLI (https://www.bitrise.io/cli) and bitrise.io (hosted service).

I'm obviously biased (CTO and Co-founder), but I love automation, that's why I'm part of the bitrise team in the first place ;)

The CLI is similar to something like rake, but the config lives in a single file which can be moved anywhere, and you can get a list of available "tasks" (workflows in the bitrise terminology) by running `bitrise workflows` or `bitrise run` without any parameter.

There's also an open source editor (UI) available for it (https://discuss.bitrise.io/t/offline-workflow-editor-workflo...), which is now part of the "base plugins" which gets installed by the Bitrise CLI. It's also really light weight, as the CLI is a single binary distribution (written in Go).

Couple of additional things:

- 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 ;)

I completely agree, just wanted to add that there are options for iOS / macOS CI in the cloud, like ours ( https://www.bitrise.io - we have a free plan for freelancers ) or Travis / Circle. Not on commodity hardware of course, and you most likely won't have macOS as an option on AWS/GCE/Azure in the near future either.. (we use a private vSphere system right now)

The tab groups feature was pretty much the only reason why I used Firefox as my primary work browser, as it managed the separation of projects / topics..

Does anyone know any alternatives (for Firefox or other browser) which can help with the visual clutter of managing 30+ tabs in an efficient way, and can handle groups as well?

[Disclaimer: Co-founder of https://www.bitrise.io , one of the alternatives mentioned on ship.io 's page]

Back when we started only a handful of CI services were available for iOS developers. One of them was CISimple which was later aquired and rebranded as ship.io . Our motivation to start our own service was that none of the available hosted services at the time were flexible enough to handle the projects we were working on.

Ship.io did improve a lot, allowing custom scripts to be executed, but, at least for us, they always seemed to be too locked down, too much of a black box.

This is exactly why we recently introduced our [open source CLI](https://github.com/bitrise-io/bitrise), so that you can run your CI and other automation configurations on your own machine if you want to, and of course in the (highly unlikely ;) case we would decide to close the shop you can still export your configuration and run it anywhere you want to.

I remember, just a few months ago, we felt that ship.io had a spy in our team, as they introduced new features almost at the same time we did (Slack support, Deliver support, ...).

It's surprising they closed so quick, they had quite an active marketing team and released new features frequently. I guess this decision was not up to the people who actually worked on the product, most likely they failed to meet the (monetary) expectations of their parent company.

Fairwell old friend, we'll always remember you!

We do a really simple trick. We have one Dockerfile, which we use for dev and for production, every configuration difference is handled through environment variables (which is easy to manage with docker-compose, Ansible, etc.), so you can run the same image everywhere and change the environment configuration to switch between dev/test/prod.

So to solve the live reload problem we do only one thing in development which we don't do anywhere else: the Dockerfile copies all the current source files into the image, but we run the container with a mounted volume of the source code - which in dev mappes exactly the same way the Dockerfile defines the src copy.

This way when you create the image and start the dev container it won't change anything, but as the src is mounted on top of the included src in the image the regular (Rails) auto reload works perfectly.

For test and prod we just simply don't do any volume mounting at all, and use the baked in src directly.

Easy and fast everywhere, all you have to control is how and when the images are created (ex: we do a full clean checkout in a new directory before building a test image, to ensure it only contains committed code. EDIT: by test I mean for local testing, while you're working on revisions, a CI server does the automatic testing).

Isn't setting up two separate projects (one for iOS on OS X and one for Android on Linux) a solution for your problem? That way you could test the two configuration separately and in parallel.