Welcome!

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

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 because of boot time. Let's jump into an example. We're assuming you're using the following, simplified, Gemfile for your dependencies: gem "rails" gem "bcrypt" gem "foreman" gem "thin" gem "newrelic_rpm" gem "airbrake" First we stop loading gems which aren't used in the code. gem "rails" gem "b... (more)

Efficiency in Development Workflows: Pull Requests and Code Review

This is a republished blog post. You can find the original source here: http://blog.codeship.io/2013/08/22/the-codeship-workflow-part-2-pull-requests-and-code-review.html Using Pull Requests As I mentioned last week we use GitHub Flow on GitHub. But the whole workflow we describe is also possible when working with BitBucket. We do not have a policy when a pull request should be opened. Some of our developers open them when they start a feature, some wait until the feature is implemented. Then we push regularly to that branch as explained in the last post. Open pull requests are h... (more)

How to Set Up Continuous Deployment to Amazon OpsWorks

Deploying code to Amazon OpsWorks using Codeship Here, at Novo IT, we love using Amazon OpsWorks for deploying our internal projects. With OpsWorks, we can easily segregate our development environments in Stacks and control how each project gets built via Chef recipes. OpsWorks binds directly with your code repository of choice. When you initiate a new build, it will pull in the latest changes and build them for you. One task, that is not immediately obvious how to solve, is triggering an OpsWorks build remotely from the command line, or from a build server. This article will expl... (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)

Efficient Development Workflows Series: Developing a New Feature

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... (more)