Taking "Deployment" Out of Web Development

By Bjarni Rúnar 2011-04-04, 15:24

Last Friday we launched an exciting new project here at PageKite: We visited a local web development company named Hugsmiðjan and kicked off a small pilot of PageKite for web developers.

Like all such programs, our goal is to get a direct feedback on how to improve PageKite, by showing a group of clever people what it is and how to use it. Any difficulties we encounter will be added to our list of things to work on; we'll iterate, improve and ultimately end up with a better product. It should be a win-win situation for both companies, as they'll get a new tool tailored to their needs - for free.

The initial meeting on Friday went pretty well; we planted some ideas and helped a few people get up and running. We were well received and I'm almost positive nobody thought we were an April Fool's joke.

We'll visit them again soon to see how things are going.

While preparing for Friday, I wrote a quick summary of the value proposition of PageKite for web developers to collect and clarify my thoughts. Now we've got the ball rolling, I can share them with the rest of you...

The theory of the cycle

PageKite for web developers is based on a theory we have, about how web sites are usually built. The theory is based in part on our own experience and in part on brainstorming and chatting over tasty beer. The pilot program should remove most of the beer goggles.

(Note that these ideas apply to almost anyone who helps builds websites for a living. Whether they are programmers or designers or graphic artists - to me, they're all developers. Also, to the ladies in the audience, please accept my apologies for using masculine pronouns all over the place.)

The theory goes something like this...

Today, most people in the web industry follow this process:

1. Create something on a desktop or laptop
2. Deploy it to a staging server
3. Show it to the client

This is a cycle: it repeats as often as necessary, until the client is either happy or the money runs out.

There are exceptions of course. Some people do all their development on a remote server, others skip deployment and just huddle around a screen together. But lots of people work like this.

Another variation of this cycle has to do with mobile devices. Sometimes "the client" isn't really a customer - it may be the web developer himself, testing an iPhone or Android device over 3G or a guest Wifi network. One common way to do this is to make his work visible to the world by deploying it to a staging server, just as if he were showing it to a client.

This development cycle has a few common wrinkles. The ones we are concerned with all have to do with steps 2 and 3: deployment and showing work to the client.

First of all, the deployment takes time. Depending on the complexity of the project it may take anywhere from a couple of minutes to a few hours. It's important to note that while the developer or designer is deploying, he is probably not doing what he does best and certainly not doing what he enjoys. He is just pushing bits around. Boring!

Another wrinkle has to do with mobility and network policies: it is quite common that access to the staging server is carefully restricted and the developer cannot upload his work unless he is physically at the office or on a network that is permissive enough to allow him to use a VPN. For mobile workers or those who frequently visit clients, this can be a problem.

Finally, there are security concerns: in-progress web designs can be quite confidential. In those cases, the developer probably has to coordinate with his sys-admin to ensure that only the client can see his site's progress. Passwords will almost certainly get e-mailed. If people are really careful, the staging server may have a TLS certificate (SSL) which in turn puts constraints on how sites can be named and organized...

Enter PageKite!

Our second theory, which we also hope to test during this pilot program, is this:

PageKite can dramatically improve developers' work flow, by eliminating the deployment stage entirely and making it easier to do the sharing in a secure way. This will lead to boosted productivity, happiness and unicorns for everyone involved.

How?

Well, PageKite makes it very easy for the developer to run a web server on his work machine. This web server gets a public DNS name and is visible from the outside world.

So, assuming the developer takes the time to install PageKite and his own web server, and learns how to use both... then from then on, he can directly expose the files he is working on to the web, eliminate step 2 entirely and skip directly to communicating with his client.

Win!

Since PageKite is designed for mobile devices and removes the need for the developer to phone home to some centralized staging server, he can travel around as much as he likes. He just needs to be sure his computer is actually on-line when it's time for his clients to take a look at the progress. And no matter where he is, the demo site will have the same name: no more futzing around with IP addresses and port numbers.

So PageKite steamrolls the first two wrinkles. What about the last, security?

Well, the PageKite service already has pretty awesome support for TLS encryption: it just works out of the box, the developer won't even need to configure anything. For the most paranoid customers, he will probably need to learn how to configure his web server's access controls though. But since creating new DNS names with PageKite is free, one "good enough" option may be to just give each demo site an unguessable name. Also, with PageKite it's really easy to just turn the demo site off when it isn't being used, which is truly as secure as it gets.

So we can help with the security wrinkle too, although I expect that's one of the areas we will need to improve on a bit more. Luckily we have some ideas...

We're pretty confident about the potential benefits of PageKite. The main question we hope to answer in the pilot program is to what degree they really matter and what we can do to make the experience as smooth as possible. Will the developer save mere minutes or entire hours? Days? Is running your own web server so hard that there are no savings at all? Can we fix that?

Of course we have almost certainly overlooked something critical. Perhaps PageKite will eliminate all justification for foosball breaks, thus ruining morale everywhere it is used?

We rather hope not, but we do look forward to finding out.

Interested?

If you think your company would also be interested in taking part in this pilot, please get in touch and we'll see what we can do!

There's still room for a few more.