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

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 pipeline it is always clear which step needs to happen next. Martin Fowler describes it really well in his blogpost. If you want to dig deeper into Deployment Pipelines I highly recommend Jez Humble and David Farley's book: Continuous Delivery. Continuous Delivery: Reliable Software Releases t... (more)

Building Vagrant Machines with Packer

Sharing a common development environment with everyone on your team is important. It is really hard though to keep the same dependencies, database versions and other systems in sync between different machines. Vagrant is a great tool that helps with this and manage the lifecycle of a virtual machine. As nice as Vagrant is, provisioning machines with it has always been a pain. A couple of months ago Mitchell Hashimoto, the creator of Vagrant, launched Packer. Packer lets you build Virtual Machine Images for different providers from one json file. You can use the same file and com... (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)

Memory Monitoring And Limiting 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 to avoid builds eating up all of your memory We couldn’t risk tha... (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)