In order to have the most successful deployment, there are a few best practices that software development teams should be mindful of. First, following a continuous delivery approach allows software development teams to release in shorter cycles, so that building, testing, and releasing can be done with greater speed and reduced error rates. As stated in an earlier post of ours, you’re doing continuous delivery when: Your software is deployable throughout its lifecycle.

I’ve recently co-founded a startup, and after working so long in more mature enterprises with diverse toolchains, it was actually massively educational to return to first steps and figure out what our critical needs were, balanced with essentially zero budget. As we’ve grown and raised money, we’ve graduated in some areas to other tools, but I wanted to share what we felt were the absolute can’t-live-without-tools for a team building SaaS software.

Deploying a new feature to production is a momentous occasion. It's important to ensure that everything goes properly at this stage, as deployments tend to be error-prone when not handled correctly. To examine why this is and how you can avoid it, let's take a look at the different types of deployments available and where some of them fall short.

Deploying a new feature to production is a momentous occasion. It's important to ensure that everything goes properly at this stage, as deployments tend to be error-prone when not handled correctly. To examine why this is and how you can avoid it, let's take a look at the different types of deployments available and where some of them fall short.

Your team is practicing DevOps and you’re delivering some flavor of Continuous Delivery. You’re deploying anywhere from three times a week to twenty times a day. You are moving fast! At that speed, how do you know if you are moving things in the right direction? Hopefully, your team has defined some key SLIs that define your application’s health.

Machine Learning (and deep learning) applications are quickly gaining in popularity, but keeping the process agile by continuously improving it is getting more and more complex. There are many reasons for this, but primarily, behaviors are complex and difficult to anticipate, making them resistant to proper testing, harder to explain, and thus not easy to improve.

Building a healthy productive engineering culture is hard and just deploying frequently with continuous deployment is not enough. I'm going to show you how you can use a carrot, not a stick, approach to take continuous deployment to the next level by celebrating team values with Sleuth.

Service alarms are going off and you are on the hook to restore stability, but you need to prevent any more changes to production while you dig further. You could "freeze" production by announcing it in the office, sending a message on Slack, or sending an email to the affected teams, but that may not be enough or may require extra work that would distract you from debugging and fixing the problem.

Today, we’re excited to announce you can now integrate LaunchDarkly with Sleuth, allowing you to track feature flags as a source of change in your DevOps stack. The Integration LaunchDarkly gives developers fine-grained control over which users see which features, and with our native LaunchDarkly integration you can now track the status and impact of feature flags relative to other source changes in your projects, such as code, issues, etc.

Software development teams are much larger than the engineers that write code. Writing and deploying code are often only the tip of the iceberg. A well oiled software team will often consist of: All of these people need to know something about what the software development lifecycle is producing and shipping, but the level of information can vary dramatically based on a team member's position. Sleuth was built to automatically generate information to satisfy each team member's needs.