Where Continuous Integration and Deployment has its home.

Manuel Weiss

Subscribe to Manuel Weiss: eMailAlertsEmail Alerts
Get Manuel Weiss via: 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)

Fast Tests in Ruby on Rails

Developers need to be able to run tests quickly or they will stop running them. Slow test suites are often partially caused by slow startup times. Once you've eliminated this problem, you might want to take a look at individual tests. Note that test suites stress your code in a totally different way from the production environment. A slow test suite doesn't mean your app will be slow in production and the other way around. Never optimize your code for the test suite. Sometimes slow tests are an indication of slow code, always measure to be sure. Measure first Always start by... (more)

Slow Tests Are the Symptom, Not the Cause

If you have a slow test suite and you are asking yourself "how can I make my tests faster?" then you are asking the wrong question. Most chances are that you have bigger problems than just slow tests. The test slowness is merely the symptom; what you should really address is the cause. Once the real cause is addressed you will find that it's easy to write new fast tests and straightforward to refactor existing tests. It's surprising how quickly a rails app's test suite can become slow. It's important to understand the reason for this slowness early on and address the real cause ... (more)

Memory Monitoring and Limiting with LXC

Original article can be found here: Memory Monitoring with LXC For a long time we didn't limit the amount of memory that you can use during your build on Codeship. There was the possibility of a bad build eating up all of our memory. A few weeks ago that bad build happened, using up so much memory that it decreased performance and eventually killed the test server. Even though we measure the memory usage of the whole test server, we didn't have the data to figure out exactly which build caused the trouble. Combined maximum and minimum memory usage of Amazon EC2 Instances. How t... (more)

Continuous Integration, Continuous Deployment and Continuous Feedback

Context At Usersnap we spend a lot of time thinking about optimizing the developer workflow. With great tech startups helping us with our tests, and Continuous Integration, we want to add Continuous Feedback to the dev checklist. Fortunately we don't need to stress the importance of receiving feedback from clients, co-workers and users before, during and after your development process. Let's move on to the how. The Build-Measure-Learn-Workflow We have all read Eric Ries' The Lean Startup - or at least we say we did - and its call for agile product development and validated learnin... (more)