Branching Out

Things have been a little quiet lately and I thought it'd be good to give an update. I left off back in April with Trunks passing one month of its public launch.

Since then, a lot has been happening, however most of it outside of Trunks. The past few months have been very busy with life offline, as well as a career change on my part.

Trunks hasn't been silent though. In April, I'd started scoping out and prototyping the next phase of Trunks. Originally, I saw Trunks as a bit of a stepping stone. I wanted something that targeted the individual developer rather than businesses and open source. At the same time I realized businesses had a lot of needs as well, but often a very different set. I planned on building a separate service after Trunks to focus on businesses.

After giving it some further thought though, I'm not entirely sure a separate service is really the way to go. And I've also found the needs of a "business" can vary greatly depending on whether they're a freelance developer, small shop with a couple of devs, or a team of 10 or 20+. So that plays in with the audience it is targeting.

So what will be coming? Will be seeing new features and a focus on small team collaboration. I will also be updating a number of portions with a focus on performance improvements, tighter monitoring integration, and clean up and reorganization of some UI elements.

The focus on small teams means features around permissions, activity streams, external integration, and APIs. Some of the features though won't work across the board with source control tools. For instance, the branching capabilities of Subversion cannot be compared in the same way as with Git and Mercurial. There will emerge more of a focus on distributed source control tools, where feature parity isn't realistic.

It was just a month ago that Trunks officially launched and I couldn't be happier. I just wanted give a quick thank you for everyone's support and feedback.

In the past month we've had two features and several interim bug fixes. Overall, it is really simple to deploy updates, generally taking about 30 seconds to roll out, or 60 seconds for the full stack (restarting services and doing database migrations).

The road ahead includes several more features and improvements and hope to continue rolling them out at the same rate. I've also started looking at the best way to break out some of the functionality to be released as open source.

Thanks again for the success of the past month and look forward to many more months and years.

Last night we rolled out a set of new features based largely on user feedback.

Webhooks!

Webhooks allows you to specify a URL that we do an HTTP POST to whenever a repository is committed to or pushed to. You can use this to trigger your own email notifications, build server integration, remote deployment, whatever you fancy!

You can set up a webhook from the Settings tab of your repository:

For more information on the payload in the requests, see our KB article.

Collaborator Emails

We've added ability to configure your repository to email you every time one of your collaborators makes a commit or pushes to a repository you have shared. This can be useful to help track what your buddies are up to.

Just like with the webhooks, you can configure this by visiting the Settings tab of your repository. Simply check the "Email on collaborator commit" option. Currently, you cannot configure the address it emails, it will just email the owner of the project.

Mercurial performance improvements

We've made a number of improvements to the web interface when browsing Mercurial repositories. We'd done some testing with larger repositories and noticed a few places where performance was suffer. Now, one thing you will notice is that we no longer list the most recent commit for a directory in the source browser. This is because the function we needed to do that would have to walk through the contents of the directory and it could get incredibly inefficient when dealing with larger repositories.

Various bug fixes

The update also includes a number of minor bug fixes we had queued up with some of the feature work.

 

Also just a plug for a new service that was born out of some of the needs for Trunk's staging environment: DummySmtp.com. DummySmtp (aka Papercut Web Edition) is a web-based email testing tool that allows you to safely send emails from a development or staging environment and view them online. More information is on my personal blog.

Keep tuned for future updates!

Last night, I pushed out a major update which included several new features including HTTP push/pull support for Git and Mercurial.

HTTP push/pull

SSH is a great way to handle authentication, however the support and workflow isn't always the best on Windows systems. The ability to use HTTP is also a convenience and allows you access to your code when SSH might be blocked, such as behind a corporate firewall.

Trunks now has full support for pushing and pulling via HTTP (actually, HTTPS, we force it to SSL). Repository URLs are https://trunksapp.com/[username]/[reponame].git or .hg. You can get the repository URL from the title area when viewing your repository.

User preferences

On your profile page, you can now choose a few preferences. The options will be growing over time, but currently you can chose your preferred source control type, so the drop down is preselected when creating a new repository. You can also specify your preferred repository URL (HTTP or SSH) and it will be the default that is shown to you.

Post-commit failures be gone!

We'd been getting a few intermittent post-commit hook failures when pushing/committing. We've rewritten our post-commit to be lighter and quicker, so long pauses after checkins should be gone and the intermittent errors a thing of the past.

Software updates

We've applied some software updates, particularly around SVN to fix some leaks we had noticed.

I first went live with our beta three and a half months ago and I've been very pleased with the results so far.

Trunks was designed to be a simple, easy to use service focusing on your personal code, be it prototypes, weekend projects, or whatever you have. It was born out of a frustration with other services which either focus on a single source control tool, or sell based on the number of private repositories. Trunks recognize that often times, developers use multiple source control tools and want a similar experience from a hosted service. Additionally, developers by nature are tinkerers and have an ever growing collection of code. With the pricing structure of others, things can get quite expensive just because of the number of projects, not disk space or activity.

The beta has been a pretty smooth ride, with only a few issues. Over time, we've been improving our monitoring to ensure the service is well cared fore and looked after. So we are peeling the beta label off and making it official.

So what does this mean for me?

This means our paid plans will now be coming into effect. If you were in our beta and signed up before March 1st, then you will be given 60 days to continue to use the service for free. After the 60 days, you can either upgrade to a paid plan for 25% off our normal price for the first year. Our base plan is $24.95/year, or $18.71 for the first year for beta users.

If you sign up after March 1st, you will instantly get our 30 day free trial. This gives you all the features and all the space you want. At the end of your trial, we will recommend you a plan based on your usage.

With both, if you convert to a paid account before your time is up, you don't lose anything. We add the time on to your trial period, so if you sign up beforehand, you don't lose that free time at all.

How do you accept payment?

To sign up for a paid plan, just visit your profile page from the top header and you will see plan recommendations on the side. Choose to upgrade and you'll be taken to a payment page where you can either pay by credit card or by PayPal.

Payments are just one-time. Since our plans are yearly, we don't keep your credit card information. We'll just make sure to remind you in advance about your renewal.

PayPal seems to be a common request that often times isn't supported. Since we already treat payments as one time, didn't see a reason to not allow PayPal. No subscription logic to account for.

You don't have a free plan?

It may sound bizarre to not be doing the freemium model these days, but freemium didn't fit in with my goals for Trunks. Other services offer public repositories for free, but we don't support public repositories. Trunks is designed for private repositories. I also wanted Trunks to be cost effective, and with conversion ratios that are considered "good" by many, freemium didn't help maintain a lower cost. Free users tend to greatly out number paid users, but then your paid users are paying for all those free users. With a service that focuses on storage, there more realistic costs than just database rows.

Any new features with the launch?

With the launch, the main new feature is viewing diffs when viewing a commit. This was the final feature I'd wanted before coming out of beta. I've also made a number of interface tweaks and improvements and a number of backend improvements to help facilitate some future features.

What is coming?

I have a number of features in the works. First up is WebDAV support for Git and Mercurial. This will help solve a problem where SSH isn't well exposed, such as on Windows with TortoiseHg. I've also been building a couple prototypes for tagging projects. One of the goals with Trunks was management of a lot of repositories, one way to make that easier is with tagging and filtering to make navigating your dashboard easier.

I'll be performing some maintenance tomorrow night to move the service to a more permanent home. After the maintenance window, you might find that the service's IP has changed. You'll need to verify the IP with the SSH key. The new IP will be 65.19.154.38 and our RSA fingerprint will remain the same, b9:74:58:26:fd:20:37:69:35:1a:80:b0:3e:3e:41:4e.

The maintenance window will be tomorrow, Wednesday February 10th from 10pm Pacific to 11pm. Actual downtime will only be a few minutes as we flip the service over, ensure DNS is updated, and ensure traffic to the old IP is forwarding to the new IP.

Registrations are now open to the public! No more invitation code... you want an account, go sign up!

After being in beta for a month and a half now, I'd decided to take one more step to open registrations up to the public before coming out of beta. So far, things have been running very smoothly but public registrations is one way to let some more users hammer away on the service before taking off the beta sticker.

Once we do come out of beta, all accounts will continue to have free access for 30 days until users will need to upgrade their account or have their account locked. This is a grace period to give users some final time to decide if they want to upgrade and move any data they have if they decide not to. Additionally, if you move up to a paid account before the 30 day grace period, any remaining time will be applied to your renewal date. So if you upgraded on the 7th of the month and still had 5 days of the grace period, your account will be valid until the 12th of the following year. I wanted to ensure all users got the full 30 days, and wouldn't be short handed for upgrading their account early.

One subject I wanted to touch on a little bit was how backups are handled within Trunks.

On our main feature list, we highlight that we perform two levels of backups: one on every commit, and another nightly backup. Both backups are to separate, offsite services.

First to touch on is the per-commit backups. These are treated as mirrors of the repositories, where they reflect the current state and do not maintain a history of changes. The main goal of these backups are for backups that are as-fresh-as-possible. You make a commit, and instantly that new data you uploaded is now stored in a second location. There is no waiting for a scheduled backup to run. We are going to convert this one to maintain history soon.

Our per-commit backups are handled by BQ Backup, a rsync-based backup solution. BQ Backup isn't necessarily a big corporate entity, but a fairly well known and established backup provider. They're mostly known among web hosts, but have been around for a couple years and are stable both hardware wise and as a business.

Next are our nightly backups. These backups are historical, where we push changes out every night, and we maintain a history of those changes for 30 days. This allows us to go back in time in the event we need to recover some older data, or something similar.

Nightly backups are hosted with Tarsnap, whose slogan is "online backups for the truly paranoid." We found that very appealing. Since our nightly backups is where we currently have our historical backups, we wanted it to be very solid, secure, and stable. Tarsnap is provides encrypted storage and transmission of data on top of Amazon S3 All data is encrypted before it leaves the system and stored encrypted for the upmost security, and it is stored on Amazon S3, where it is easily scalable and synchronized across Amazon's data centers. What more could you want?

With the combination of the two methods, I am confident our backups are both flexible and secure.

I am pleased to announce that collaborators are now live! Collaboration was the main feature that was on our launch list that wasn't complete yet, and now I glad it is a go.

How does collaboration work? Collaboration is an easy way to allow you to share access with a repository of yours to other users. The other users will have write access to the repository, but won't have permission to edit any of the settings.

To add collaborators to one of your repositories, go to view your repository and go to the settings tab. In the Collaborators section, you can type in the username of another user and click Add Collaborator to grant them access. Pure and simple.

If you are added as a collaborator on a repository, it will show up on your dashboard in a Collaborations section below your own repositories.

Yes, we are live! I am very excited to finally be able to show Trunks off and open it up. If you want to sign up, please hit the homepage and fill out your email address in the green box!

Currently, we are just having a limited beta. At first, I mainly want to gauge what the app's performance is and slowly add more users into the mix. Rest assured I will be gradually adding batches of more users as I try to get a good baseline on the performance.

So where are we currently? Trunks fully support SVN, Git, and Mercurial. You can create your repositories, browse the source, and browse commits. You can manage your profile and your SSH keys.

What is to be coming? There is still a good amount. Currently, Trunks isn't displaying diffs with the commits. I need to add that back in after refactoring some stuff. Bazaar support needs to be finished. Additional features down the road are deployment keys (including deployment users for SVN), collaboration, and going to be putting a lot of thought in efficient navigation of lots of repositories. There will also be some features I'll throw in here and there.

How long will the beta last? I am not looking for a long beta. I would expect it to end before Christmas. I don't expect to have every single feature in before then, but I expect to have everything advertised (collaboration and such), as well as any bugs that creep up stamped out. Since I've had Trunks up for almost a year, but only open to a few friends, I expect it to be fairly stable.

How can you report issues? When in the app, just click the Help button either in the header or footer, or head over to the Support Portal.

Did you see the pricing? With the beta, I've also decided to make pricing known. You will find the pricing page has full details. We've aimed to keep the service as low-cost as possible, but also without cutting corners. There is a fine line between making it cheap and valuing your own work though. My hope is to find a nice balance. The reality is I am not starting this service to get rich, else I wouldn't have chosen these prices. Rather, I wanted others to enjoy the service as much as I do, and wanted to make it accessible. Pride in your work is worth more than dollars can make up for... in most cases. :)

How often will you deploy updates? As frequent as I have new stuff to show and I'm confident in its stability. With bug fixes, I hope to push them regularly, so will likely maintain two branches so I can deploy fixes safely ahead of features. I will likely have a regular maintenance window of 11pm-12am, with posted notices of updates 18 hours in advance (may post in the morning that we're updating that night). I'd expect main features pushes to be Sunday nights, as I'll likely develop them over the weekend.