Release[Board] Blog

Tuesday, January 21, 2014

Release[Board] Announces Jira Integration

Release[Board] is happy to announce integration with Jira issue tracking software by Atlassian.

The goal of Release[Board] has always been to make the release process smooth, efficient & complete. For this reason, we have brought two important aspects of the development cycle together: development tracking and the release process.

This update allows users of Release[Board] to import issues from their Jira account and assign them to releases created in our application. After setting up the connection, you’ll have a direct link between issue tracking and release planning.

In order to set up the connection between Release[Board] and Jira, you must first go to your account’s settings page:



Once on the Settings page, click to the APIs tab and click Connect.




We’ve created a guide to complete the process on this page.

In creating this integration, we were faced with the choice of making the setup process extremely fast (with only a couple of steps), or keeping sensitive data extremely secure. Since the security of sensitive data is of utmost importance to us, we were forced to use a slightly longer setup process.

If you have any difficulty linking your Jira account to Release[Board], please don’t hesitate to contact support via our widget on every page or directly via email: support@releaseboard.com.


Once integration is complete, you’ll be able to access the new feature on the Releases page. In the expanded view, a release now has an Import link.




By clicking “Jira issues”, you will be presented with a list of issues in your Jira account. Select the issues you want to import to the current release and click Import.




We hope you enjoy this new feature and the productivity it brings to your software release process!

Sunday, December 15, 2013

Angular JS Gotcha #2 - HTML5 Mode

Angular JS has an official plugin for routing called angular-route. I believe in older versions of angular angular-route was included with AngularJS, but it has since been extracted into its own module.

Angular-route has Hashbang mode and HTML5 mode. Hashbang mode is the default mode and results in ugly urls: app.releaseboard.com/#!/releases. HTML5 mode rewrites your urls to look like standard urls: app.releaseboard.com/releases.

At this point you may be wondering why Hashbang mode is the default mode for AngularJS if it creates non-standard urls. I came to the same question when starting to develop Release[Board] with HTML5 mode enabled. I soon discovered that there is a lot of hidden complexity behind enabling HTML5 mode in your AngularJS application.

The first roadblock I came across is that HTML5 mode is not supported by all browsers (If you're reading this with Internet Explorer, please upgrade to a modern browser!) Fortunately, AngularJS solves this problem by allowing your application to fallback to Hashbang mode by adding hashPrefix.

The second roadblock, I came across is that HTML5 mode requires a web server! If you plan on hosting your AngularJS application as a static web page on Amazon S3 or a similar service and punt on worrying about scaling, you can't! Unfortunately, this shortcoming is not immediately obvious. HTML5 mode will work on a static site when you first turn it on. However, as soon as you go to a non-root page of your application (/releases) and refresh your browser, your application will break!

The reason why refreshing your browser breaks HTML5 mode is that all the routes in your AngularJS application are not real. Release[Board] doesn't have a /releases page. AngularJS is using some clever JavaScript to make it seem like a /releases page exists. When the user hits refresh, the browser tries to load a real /releases page, which is non existent. I find this a completely unacceptable user experience.

Fortunately, there is a solution to make refreshing an HTML5 mode AngularJS app not crash: use a web server that allows url rewriting. In an AngularJS application, the only real web page is the root (/). Using a web server with url rewriting, you can have all requests redirect to root so that your AngularJS application can interpret the url and display the page correctly.

When I hit this issue while developing Release[Board], I couldn't find any simple nodejs web servers that allowed url rewriting. Lucky for you, I forked a repository called Statik and added url rewriting (https://github.com/limitingfactor/statik). At Release[Board], we used a node web server but you can easily use Ruby, PHP, or some other language. The only requirement is to have a way to point all requests to root to prevent browser refreshes from breaking your app.

Thursday, December 12, 2013

Angular JS Gotcha #1 - Shared scope variables

While developing Release[Board] using AngularJS, my co-founder and I have run into a few not so obvious quirks of the AngularJS framework. This is the first post in a series of blog posts about some of the most frustrating framework behavior we have come across while developing Release[Board].

In a complex page, it is possible to end up with one angular controller nested inside of another.

Angular allows you to nest controllers and even share scope variables between the parent and child controllers. The Gotcha occurs when you attempt to modify the parent scope from the child scope. In this situation, the child scope will create a copy of the scope variable that is accessible only to the child controller. As a result all the references to the variable from the parent will not be updated when modified from the child controller. This data-binding breaking behavior may leave you wondering why parts of your page are updating and others are not.

 To remedy this issue, add a setter method in the parent controller and call the setter method in the child controller instead of modifying the variable directly. 

Thursday, October 10, 2013

Releasing Software is a Broken Process

My co-founder and I are building Release[Board] because we are frustrated with the current state of releasing software. Every company we have worked at has had a process that only exacerbates an already stressful process by adding disorganization, lack of communication, and lack of transparency. Releasing software is a stressful process because when an application’s logic changes many things can go wrong. Maybe an edge case was missed in the application logic or maybe customers are going to hate the design that your team just spent 6 months implementing.

A terrific software release is an uneventful one. Software teams love releases that follow a timeline of chores and go exactly to plan. Most releases follow this pattern as the risks of deploying new code are mitigated by unit tests, integration tests, test environments, and other development tools. It’s that one release that didn’t run smoothly and customer support got hammered with calls and everyone was furiously trying to figure out what the release broke that is in the back of every developer’s mind. At some time during their career whether it was once or several times a developer has been through a nightmare release and the thought of another haunts them as they hit the deploy for the next one.

With Release[Board], we are trying to build a centralized application that serves as a dashboard and documentation for your release process. We can’t fix your applications’ unforeseen bugs, but we can bring structure and organization to your release process so that when something does go wrong, you have all the information you need to patch your bugs.

One of the staples of any release are release chores. Release chores are usually database migrations, data manipulations, scripts, database backups, maintenance pages, and many other essential tasks that if not done in the correct sequence can quickly turn an otherwise perfect release into a nightmare. At Release[Board], we have made release chores a first class citizen of our application. Never wonder if again if a data base backup was successfully completed. Release[Board] eliminates common release questions like: Did Tom turn on the maintenance page yet? Did Jimmy run the database migrations yet? Did Mike run our script to fix the usernames with invalid characters? Can I start running my post release test suite yet or is the team still working on deployment tasks?


Release[Board] allows a team to assign chores to the appropriate team members and allow a team member to opt into an email reminder when their task is approaching to make sure they don’t forget. In addition to email reminders, Release[Board] has a live release dashboard that gives all team members a real-time look into the release process. Release[Board] presents release chores visually as a vertical timeline of chores and the time they are scheduled. As team members begin to complete their chores in sequence the live release dashboard automatically updates without requiring the page to reload or having team members manually refresh the page. When one member updates or completes a task all members’ view of the dashboard is updated immediately courtesy of HTML5 web sockets.

The real-time functionality of our dashboard is a critical part of the value Release[Board] brings to a software team. Everyone on your team can be on the same page about the status of a release without delay. No shouting across offices or waiting for a long email chain of release updates to be written. Any information asymmetry about your release’s status whether your team is remote or in the same office is eliminated from developers to ops to management.

For those members who do not have any chores completed but who would still like to know how a release went, Release[Board] sends out a release summary to all members who subscribe to it in your organization. The release summary provides your organization with a summary of features added, chores completed, and many other release tidbits.

The value Release[Board] brings to a software team however is not just limited to release day. Release[Board] allows your team to schedule releases for any project in your company. With Release[Board], it’s easy to coordinate and schedule releases across projects and ensure that there are no conflicts. With everything about a release visible to any member of your organization, 
you can ensure that schedule conflicts like marketing holding an online webinar demo of your product while your development team puts your entire application into maintenance mode are avoided. 


We believe that one of the cornerstones of a successful software team is communication. Communication is key for every aspect of a software team from design to release. While many teams have tools to manage user story development and chat applications to discuss code challenges, releasing software has been forgotten. It’s time we fix that flaw in our processes. Release[Board] gives your company an organized, central, and real-time look into your companies release process from planning to deployment. It’s time to bring structure and accountability to your company’s software releases. We encourage you to give Release Board a try. There’s no tool other on the market that makes software releases a priority.

Wednesday, October 9, 2013

Mock Driven Design

Designing a web application from scratch can be an overwhelming proposition. With so much flexibility and much conflicting advice from experts, it can be difficult for a developer to make progress building an application. It’s an easy trap to start working on a project and then learn about a different seemingly better approach which results in a rewrite of whatever work has been started. My advice is to pick a development process and stick with it even when you begin to second guess yourself. 

A complete project that ships is better than a perfect project that is stagnant. By no means does that mean I think that a product should be shipped without much thought. I firmly believe that a software product should be solid from code to user experience. However, when given the choice of choosing between code and user experience, I give preference to the latter. As a result, I like to call my process for developing an application mock driven design.

Mock driven design makes the look and feel of a software application a first class citizen in the development process. Unlike some processes that start with actual code of an application and then tack on design and user experience at the end of the process, mock driven design starts with a story board like overview of an application. This approach works particularly well for modern web applications which are data driven and have very few unique pages (sometimes just one). 

Once the application’s pages are mocked, discussion begins about how to turn a couple of mocks of a web page into a fully featured application. Where does the add user functionality go? Where do I place our release timelines? What does a release timeline look like? Is it a better experience to have a vertical or horizontal timeline? All these decisions are made with the user at the forefront of developers’ minds and the entire process revolves around the business logic of the app.

 During the whole process developers aren’t talking about models, views, controllers, they’re talking about timelines, credit card payments, release emails, and other jargon specific to the problem they are tackling. The terrific benefit of this process is that not only does the team make development an implementation detail which makes the entire process fluid, but the team also better fleshes out the details of the product. Not a single team member has written a single test or line of a code which gives the team the flexibility to pivot based on the improved domain knowledge they have gained by learning the workings of their project’s business logic.


I want to note that mock driven design is process for a team. This process immediately breaks down if developers are left out of the loop, which is the most common use of this system. The benefits of having team members who know what is technically possible and have knowledge of the business domain before writing any software is lost if the process is left to product managers and designers. Mock driven design should be a team wide process that has every team member participating on the design process as a group. If team members are being left out of design discussion, you’re doing it wrong.

Tuesday, October 8, 2013

Hipchat - The tool your team is missing

Communication is one of the cornerstones of a successful software team. It’s important to foster an environment where team members can work together to tackle difficult challenges or strategize about how to approach a problem. In my view, communication is critical to developing a top product. With so many issues that arise on a daily basis in a startup or within a team in a larger company, it is imperative that developers be able to unblock themselves from a problem as soon as possible and the most efficient way is to ask for help.

Over the last few months, I have started using the messaging service, Hipchat, and I find it to be the best communication tool for a software developer short of face to face communication. With Hipchat, I can envision a future where teams can work remotely without experiencing crippling communication issues that are so often talked about in the tech industry. At Release[Board], we’re using the free plan which makes the standard of their service all the more impressive.

What makes Hipchat so great is that it goes beyond being a chatroom for developers. Hipchat is the activity feed of your startup or team. In addition to the standard private chatroom features like statuses, private conversations, and actual chat rooms, Hipchat has integrated itself with seemingly every other SAAS product we use. When someone pushes a Github commit, everyone on your team is instantly notified and given a link to check the commit. This is incredibly useful for when someone pushes a commit right after you did a pull, but you haven’t pushed your changes yourself. Avoid the unattended merge commit or conflict! 

Another useful Hipchat integration is with a service called Zapier, which also has a free starter plan. Zapier is a service to connect services. Yes, it’s kind of meta. With Zapier + Hipchat the number of services that you can use to update your Hipchat room is seemingly endless. Have a notification sent when a user charges their credit card with Stripe. Send a notification to your team when you receive a customer support request with Olark or UserVoice. Send a notification to your team when someone signs ups for your product or requests an invite to your private beta launch. The list of uses is seemingly endless.

The huge bonus that Hipchat provides is that all your chats are persisted. At Release[Board], we have been using Hipchat since day one of development and it is amazing to have a log of our history from the first minute to present time. Having a journal of your team or startup’s history can be incredibly useful for making improvements to your processes or documenting your workflow.


I’ve find myself turning off email notifications in favor of using Hipchat notifications. Not having to deal with my inbox, marking something as read or unread, or deciding whether to delete a message or keep it is a huge plus. I can definitely see Release[Board] having a Hipchat integration itself down the road to give our technical users an alternative to our email notifications.

Monday, October 7, 2013

Product First

When it is time in your new business cycle to focus on the technical aspects of your software business it’s important to put your product (business logic) above all else. The great news is that it has never been easier to push back on secondary tasks by delegating to outside services.

At Release[Board], once we began working on building our product after receiving validation from the market, it was important to move quickly and be smart. Our focus was on building an amazing product for our customers above all else. Non-customer facing tasks were delegated to trusted outside services instead of rolling our own solutions for some tasks which would waste months.

One of the main delegations we made was to push our operations’ work to outside services for launch. Instead of rolling our own servers and having to worry about maintenance and setup for each server, we decided to use Amazon Web Services and Heroku to host our software. Not only is this decision incredibly beneficial to us in time and cost, but it allows us to spend considerable more time and energy focusing on improving our product for customers.

Another delegation we made was also an infrastructure decision. Instead of maintaining our own email servers we chose to use Google Apps to host our businesses’ email accounts. When you email us at *@releaseboard.com, our email is powered through Google. Just like the web servers, having an email server hosted in the cloud is a wise decision for a new company. While moving to your own servers and out of the cloud makes complete sense as your business grows, it makes no sense in the early stages of your company.

A single web server for Release[Board] would cost us over $20,000 and if it failed we could be out that entire price and our software could be offline for days. In contrast, our total Heroku and Amazon bill is around $100 per month. If one of their servers fails, they just move us to another one in seconds. With the huge savings we receive with using the cloud, we can reinvest thousands of dollars into improving our product for our customers instead of on an aspect of our business that’s not visible to customers.

Other areas where it makes sense to use some incredible third party software services instead of building your own are email delivery, customer service widgets, application analytics, software productivity, and hosting your company blog. Many of these services can be integrated with your application in as little as 5 minutes. When the decision is a month of development in which you neglect your core products versus a low cost per month third party service that takes 5 minutes to setup, there shouldn’t even be a debate.


At Release[Board], we take full advantage of using trusted services wherever they make sense. After all, we are a service for your software company. You could spend $250,000 in developer time developing your own version of Release[Board] or you could use our product which is updated on almost a daily basis for a low monthly fee. The true power of the cloud is leveraging it to increase your business’ productivity. Focus on your core mission and delegate wherever possible to boost your organization’s growth.

Wednesday, October 2, 2013

Why does Release[Board] use AngularJS?

I’ve been following the Client side Javascript framework explosion of the last few years with mild curiosity until recently. Do I really need a framework to manage my JavaScript code? Isn’t using an awesome library like jQuery enough?

I then began to experience some of the problems that the frameworks claim to solve. Why is testing JavaScript code so much harder than testing Ruby code?  How can I organize my JavaScript code more efficiently? Why am I always checking multiple files to find where I defined a function?

My first attempt at using a JavaScript framework was Backbone JS. I read some articles and then took a few online tutorials to try to get a grasp of the framework and its benefits. After spending a few hours trying to learn Backbone, I gave up. In my view, there was just too much boilerplate code. Spending most of my day writing Ruby code, I have been spoiled by the succinctness of the language, and all the lines of code generated just felt ugly in comparison. I didn’t really see an improvement in testing my JavaScript either. I’ll stick with my jQuery mess instead.

Months went by and I kept on hearing about a new JavaScript framework seemingly every day. Try Meteor, Try Batman,... None of the frameworks caught my attention beyond seeing yet another implementation of a Todo List. (http://todomvc.com/). Then I kept on hearing more and more about a framework called EmberJs. It seemed interesting: Bring the mantra of Ruby on Rails of convention over configuration to a JavaScript framework. Since I love using Ruby on Rails. It seems like a perfect fit. I read some tutorials and watched several screencasts with sample applications built using Ember. I thought that since there were Ruby on Rails core members also on the Ember team integration would probably be really easy, but I never got that far. Just like Backbone, I just couldn’t fully wrap my head around the framework, and I didn’t get the impression that testing would be much easier than my current jQuery mess. The time investment to really understand the framework didn’t seem worth it to me.

So I took a break again, and I kept on hearing about more JavaScript frameworks. Try Knockout. Try Derby. Try Angular, it’s built by Google. Maybe this Angular framework may be worth looking into. If it’s backed by Google, it might pick up traction. My first impressions of Angular were actually quite negative. You mark up your html with logic and the syntax makes your html document invalid. What?!? Those first impressions were enough and I again decided to stick with my jQuery mess over invalid HTML, but I kept on hearing more and more positive reviews about Angular. The Railscast on Angular was about 1/2 the length of the Ember one that built the same application. Maybe I’ll have to give Angular another shot... I read some tutorials and watched some screencasts and things began to click for me. Angular uses Dependency Injection. Hey, that will make it easier to test my JavaScript logic! Hey, I can separate my JavaScript code similarly to my Rails code with Models and Controllers!

Now, having used AngularJS for several months I can say that I don’t even want to use jQuery with Angular. I didn’t think I would be throwing away my favorite library a few months ago. Clearly for what I desired Angular delivered. Testing is significantly easier and my code is better organized, and that’s why we’re using AngularJS to power our web application at Release Board. My co-founder also explored the JavaScript frameworks and settled on AngularJS after trying out a few JavaScript frameworks as well, but that’s for another blog post.


While AngularJS was the perfect fit for me, this post isn’t intended to bash the other frameworks. There are some really talented people working on them and they very well may have significantly changed since I last tried them. My advice is to think about what frustrates you the most about your current JavaScript development process and try out the frameworks that best solve your frustrations.

Tuesday, October 1, 2013

Why Release[Board] is hosting our static HTML website on Amazon S3

As a Ruby on Rails Developer, I surprised myself by making the decision not to use Ruby on Rails to host our landing pages for Release[Board]. Using Heroku to deploy a simple Ruby on Rails application is almost trivial so why bother breaking my current work flow and using an S3 bucket to host Release[Board]’s landing pages?

On my last project I used the former approach and unfortunately the smooth deployment process that Heroku provides came with a cost. While setting up my app was a pleasurable experience, dealing with the site’s performance on the Heroku platform was not.

If you are using Heroku’s 1 dyno free plan, site inactivity can result in the next visitor to your site having a very long load time as the dyno gets set to idle and then has to be restarted when a new visitor visits your page. If you want to prevent this behavior, you must purchase another dyno from Heroku for your app, which is a $35 per month charge. 

In contrast, Amazon’s charges for a site with 30,000 page views per month is around $5 per month, which is a significant discount over Heroku. In addition, there is no idling of your service. Another huge advantage is that Heroku’s apps are hosted in a single Amazon region (Heroku uses Amazon behind the scenes). By bundling Amazon’s S3 service with Cloudfront your application can be served from all Amazon regions. If someone from South America tries to access your app they will receive your site from the Amazon South America server instead of having to communicate with a server in North America. This is a HUGE boost to your site’s response time world wide. Unfortunately this is a feature that is not available on the Heroku platform.

Additionally, it took a considerable amount of work to get caching working in Rails for static html pages. Setting etags, flushing etags on new deploys, having Rails in development mode ignore etags (I want to be able to see my changes in development without have to reset etags for each change!), etc. With Amazon S3 + Cloudfront, Http caching is set by default and can be easily configured in the Cloudfront dashboard, and I can avoid using Rails for behavior that it is overkill for.

I have been harsh on Heroku in the above paragraphs. I want to reiterate that my preference to use Amazon is only for the static html portions of a web application. Release[Board] will be using Heroku in addition to Amazon for our web application. Our service oriented architecture gives us the flexibility to use Amazon for our static HTML, Javascript, and CSS, and to use Heroku for our Rails API application. For the Ruby portion of our architecture the flexibility of Heroku and its huge marketplace of one click to install add ons can’t be beat. I’d rather not have to worry about server, language, database maintenance and other ops tasks in the early stages of building a product, which is a tradeoff of using Amazon’s EC2 platform.


My advice is to use Heroku and Ruby when needed instead of trying to put all functionality into one monolithic application.

Monday, September 30, 2013

Building a Web Application for 2014

There has been a shift in the web application community over the last year or two. More and more software conference speeches feature a developer explaining how he or she built their web application with a services oriented architecture. Service oriented architecture is hardly a new idea, but it was considered an unnecessary complexity for most web applications until recently. 

The addition of mobile applications to the software landscape in the past few years has resulted in a huge increase in businesses implementing a service oriented architecture. More and more consumers now use native mobile applications on their iPad, iPhone, and/or Android device. A web application is quickly becoming inadequate for businesses in most fields. Consumers’ preference for a native application over a mobile version of a website is readily apparent, which is no surprise given the clear preference by Google and Apple to design a better user experience for native applications. This presents several problems for most web based businesses: How do I efficiently develop a web application for my desktop and notebook users while also having a mobile app? Do I have to rewrite all my business logic in another language or is their some way to leverage my existing codebase? 

A business’ need for multiple applications on different platforms is an area where a service oriented approach really shines. Instead of a team duplicating all of the company’s logic, it can create a single service or many services that handle all business logic for your web application and mobile application. By designing a RESTful JSON API in the language of your choice (we prefer Ruby here at Release[Board]), you can have your web application and mobile application call the same API endpoints which trigger the same business logic. How’s that for DRY?

At Release[Board], we decided to have a services approach from the onset. The services approach creates an initial increase in complexity and setup time, but the benefit of separating client and server concerns is too big of a win to pass up. Not only will our customers experience a web application with the performance of a native application thanks to the web application having been built with AngularJS, but we have given ourselves the flexibility to develop a native application in the future.

 Keeping our Ruby on Rails service platform agnostic also should simplify the application and make it easier and faster to test by avoiding the view layer. Additionally, the AngularJS app will be built using Yeoman, which makes JavaScript testing easy and transparent. In my experience, Javascript tests are usually hidden deep in the spec folder of a Ruby on Rails project or non existent. By having Javascript tests at the top level of the Yeoman project they can’t be easily ignored. Is it really 100% test coverage for a web application when you have zero JavaScript tests?


While I’m just scratching the surface of the benefits of a service oriented architecture, I encourage you to research for yourself the benefits of starting with a service oriented architecture for your next project.