Where Continuous Integration and Deployment has its home.

Manuel Weiss

Subscribe to Manuel Weiss: eMailAlertsEmail Alerts
Get Manuel Weiss: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Top Stories by Manuel Weiss

This is a republished blog post. Original source: http://blog.codeship.io/2013/08/16/the-codeship-workflow-part-1-developing-a-new-feature.html With this blog post we start a new series about how we work on the Codeship. Many people asked us how we develop features, about our workflow and which apps we use every day. This blogpost focuses on the workflow to implement a new feature. From branching away from master until it is ready for the pull request. The following blogposts will talk about our internal communication, how we do pull requests and code reviews and an in-depth look into our deployment strategy. Git branching model We follow the Github-flow model of development (check out Scott Chacon's article, so whenever we start a feature we create a feature or bug branch. Most of our team usesgit-extras by visionmedia for this. Typically only one person works on ... (more)

Faster Test Suite Boot Times with Ruby on Rails

Developers need to be able to run tests quickly or they will stop running them. The biggest bane of test driven development, or whatever variant you practice, is long boot times. Even when you just run one test a slow boot will make it a tedious job. There are a number of ways to reduce startup times in a Ruby on Rails project. Load less dependencies to get a faster test suite boot time Project dependencies need to be loaded every time you start your test suite, less dependencies means faster startup. Keeping project dependencies to a minimum is always a good idea, not just beca... (more)

Efficiency in Development Workflows: Deployment Pipelines

Last week we talked about how we review code, open pull requests and use GitHub issues to manage our development workflow. This week I will show you every step that happens after a pull request is merged into our master branch. We use an automated deployment pipeline for releasing our code into production. Deployment Pipelines A deployment pipeline lays out the whole process that your code needs to go through from your repository to production. It breaks the build into several parts (e.g., build, test and deploy) and all the associated steps that need to be taken. By defining a p... (more)

How to Build a Google Glass Integration in Under Two Weeks

How we built our Google Glass integration in less than 2 weeks I am happy to announce that we have officially launched our Google Glass integration for Crushpath along with an updated version of our Promotion and Social Monitoring features. In this post, I am excited to discuss why we picked Glass and how we achieved the integration in under 2 weeks. At Crushpath our mission is to help people, in particular, small business owners and entrepreneurs, quickly pitch their business to potential customers. Pitching is not a one time thing, it's about establishing a dialogue and giving p... (more)

How to Deploy a node.js App from GitHub to Heroku

In this blog post we're gonna deploy a Node.js application from a GitHub repository to Heroku using the Codeship. We've set up a simple Node.js application called codefish which contains some Jasmine specs. We'll use screenshots of this application in this blog post. If you don't have an own project to set up but you want to follow along on your computer, just fork the repository. Together, we're gonna deploy this application to Heroku using the Codeship. First, sign in to the Codeship with GitHub. The Codeship needs access to your GitHub repositories to be able to set them up. ... (more)