The Shippable Blog

NEW: Debugging with SSH (And Why We Don't Like It)

I am very happy to announce that we've launched a frequently requested (and internally controversial) feature: the ability to SSH into build machines to better debug your CI/CD jobs. I say controversial because being a team of over 20 strong minded people, each person had a distinct opinion on the merits and demerits of debugging with SSH. 

The merit is obvious, debugging is much faster when you can see what's happening on the machine. You can print out the environment, or see what happened to a particular container, look at CPU/memory utilization, or even change the configuration of a test database to see if that helps your failing tests. 

However, our team has made a conscious decision to disallow SSH access for our developers for two main reasons:

  • It doesn't encourage a mentality of 'designing for failure', for example, adding sufficient logging or making sure you can collect the information you need without needing access to the machine. You're not going to have access to Production machines, so avoiding SSHing into Test machines will build the discipline of designing for failure, rather than just reacting to failure.
  • Making ad-hoc changes to the machine environment results in environment drift and often, these changes aren't documented or really applied in all environments. Making it work on one Test machine isn't the goal, the discipline needed to then propagate those changes to all environments and reconfigure them is sometimes missed, which means your job will just fail again when your code change reaches the next environment.

Regardless, many of our customers still wanted this feature, so we're happy to launch it today. 

Before we dive in deeper, you need to know that SSH access is only available for paid accounts. 

Setting up nightly builds on Shippable

Nightly builds means running an automated build for a project once a day, usually after the end of the day. It is often a good practice run automated builds every time you make some change to your codebase. These automated builds help you maintain a healthy code base.

Automated builds help in finding out a number of problems like:

  • A team member checked in something that breaks the codebase.
  • Your dependencies have changed and they break your code.
  • Your dependencies are broken.
  • Your build scripts or build machine is broken. 

Nightly builds ensures that you catch such problems within 24 hours of when they occur.

Feature roundup: Amazon ECR regions, Service status page, Github tag/release builds, and more!

Feature roundup: Hipchat integration, faster caching, code coverage badge, and much more

We hope you're enjoying using the new Shippable. Now that we're a month past the release and all customers are on the new build platform, we have started knocking off new features at breakneck speed!

Improved integration with Atlassian products

We've added support for commit status of Bitbucket pull requests so you can now view build status for your pull requests from within Bitbucket UI. We also added Hipchat notifications for CI and Pipeline workflows. More on that in a separate blog post to be published later today. 

New caching implementation

Shippable now supports folder level caching so you can cache selectively depending on your needs. The new caching implementation is fast and can save you several minutes in build times! Read more in our documentation about caching.

DevOps 2.0 is here - Announcing Shippable Formations and enhanced CI capabilities

 

We are excited to announce the release of significant enhancements to Shippable Continuous Integration and the introduction of a new product, Shippable Formations. Together, these two products transcend traditional DevOps and take it to the next level, to DevOps 2.0. 

DevOps 2.0 - Frictionless pipelines from code to production