The Single Responsibility (SRP), Open/Closed (OCP), Liskov Substitution, Interface Segregation, and Dependency Inversion. Five agile principles that should guide you every time you write code.

Because both the Liskov Substitution Principle (LSP) and the Interface Segregation Principle (ISP) are quite easy to define and exemplify, in this lesson we will talk about both of them.

Liskov Substitution Principle (LSP)

Child classes should never break the parent class' type definitions.

The concept of this principle was introduced by Barbara Liskov in a 1987 conference keynote and later published in a paper together with Jannette Wing in 1994. Their original definition is as follows:

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

Later on, with the publication of the SOLID principles by Robert C. Martin in his book Agile Software Development, Principles, Patterns, and Practices and then republished in the C# version of the book Agile Principles, Patterns, and Practices in C#, the definition became known as the Liskov Substitution Principle.

This leads us to the definition given by Robert C. Martin:

Subtypes must be substitutable for their base types.

As simple as that, a subclass should override the parent class' methods in a way that does not break functionality from a client's point of view. Here is a simple example to demonstrate the concept.

class Vehicle {
    
    	function startEngine() {
    		// Default engine start functionality
    	}
    
    	function accelerate() {
    		// Default acceleration functionality
    	}
    }

Given a class Vehicle - it may be abstract - and two implementations:

class Car extends Vehicle {
    
    	function startEngine() {
    		$this->engageIgnition();
    		parent::startEngine();
    	}
    
    	private function engageIgnition() {
    		// Ignition procedure
    	}
    
    }
    
    class ElectricBus extends Vehicle {
    
    	function accelerate() {
    		$this->increaseVoltage();
    		$this->connectIndividualEngines();
    	}
    
    	private function increaseVoltage() {
    		// Electric logic
    	}
    
    	private function connectIndividualEngines() {
    		// Connection logic
    	}
    
    }

A client class should be able to use either of them, if it can use Vehicle.

class Driver {
    	function go(Vehicle $v) {
    		$v->startEngine();
    		$v->accelerate();
    	}
    }

Which leads us to a simple implementation of the Template Method Design Pattern as we used it in the OCP tutorial.

Based on our previous experience with the Open/Closed Principle, we can conclude that Liskov's Substitution Principle is in strong relation with OCP. In fact, "a violation of LSP is a latent violation of OCP" (Robert C. Martin), and the Template Method Design Pattern is a classic example of respecting and implementing LSP, which in turn is one of the solutions to respect OCP also.

The Classic Example of LSP Violation

To illustrate this completely, we will go with a classic example because it is highly significant and easily understandable.

class Rectangle {
    
    	private $topLeft;
    	private $width;
    	private $height;
    
    	public function setHeight($height) {
    		$this->height = $height;
    	}
    
    	public function getHeight() {
    		return $this->height;
    	}
    
    	public function setWidth($width) {
    		$this->width = $width;
    	}
    
    	public function getWidth() {
    		return $this->width;
    	}
    
    }

We start with a basic geometrical shape, a Rectangle. It is just a simple data object with setters and getters for width and height. Imagine that our application is working and it is already deployed to several clients. Now they need a new feature. They need to be able to manipulate squares.

In real life, in geometry, a square is a particular form of rectangle. So we could try to implement a Square class that extends a Rectangle class. It is frequently said that a child class is a parent class, and this expression also conforms to LSP, at least at first sight.

But is a Square really a Rectangle in programming?

class Square extends Rectangle {
    
    	public function setHeight($value) {
    		$this->width = $value;
    		$this->height = $value;
    	}
    
    	public function setWidth($value) {
    		$this->width = $value;
    		$this->height = $value;
    	}
    }

A square is a rectangle with equal width and height, and we could do a strange implementation like in the above example. We could overwrite both setters to set the height as well as the width. But how would that affect client code?

class Client {
    
    	function areaVerifier(Rectangle $r) {
    		$r->setWidth(5);
    		$r->setHeight(4);
    
    		if($r->area() != 20) {
    			throw new Exception('Bad area!');
    		}
    
    		return true;
    	}
    
    }

It is conceivable to have a client class that verifies the rectangle's area and throws an exception if it is wrong.

function area() {
    	return $this->width * $this->height;
    }

Of course we added the above method to our Rectangle class to provide the area.

class LspTest extends PHPUnit_Framework_TestCase {
    
    	function testRectangleArea() {
    		$r = new Rectangle();
    		$c = new Client();
    		$this->assertTrue($c->areaVerifier($r));
    	}
    
    }

And we created a simple test by sending an empty rectangle object to area verifier and the test passes. If our Square class is correctly defined, sending it to the Client's areaVerifier() should not break its functionality. After all, a Square is a Rectangle in all mathematical sense. But is our class?

function testSquareArea() {
    	$r = new Square();
    	$c = new Client();
    	$this->assertTrue($c->areaVerifier($r));
    }

Testing it is very easy and it breaks big time. An exception is thrown to us when we run the test above.

PHPUnit 3.7.28 by Sebastian Bergmann.
    
    Exception : Bad area!
    #0 /paht/: /.../.../LspTest.php(18): Client->areaVerifier(Object(Square))
    #1 [internal function]: LspTest->testSquareArea()

So, our Square class is not a Rectangle after all. It breaks the laws of geometry. It fails and it violates the Liskov Substitution Principle.

I especially love this example because it not only violates LSP, it also demonstrates that object oriented programming is not about mapping real life to objects. Each object in our program must be an abstraction over a concept. If we try to map one-to-one real objects to programmed objects, we will almost always fail.

The Interface Segregation Principle

The Single Responsibility Principle is about actors and high level architecture. The Open/Closed Principle is about class design and feature extensions. The Liskov Substitution Principle is about subtyping and inheritance. The Interface Segregation Principle (ISP) is about business logic to clients communication.

In all modular applications there must be some kind of interface that the client can rely on. These may be actual Interface typed entities or other classic objects implementing design patterns like Facades. It doesn't matter which solution is used. It always has the same scope: to communicate to the client code on how to use the module. These interfaces can reside between different modules in the same application or project, or between one project as a third party library serving another project. Again, it doesn't matter. Communication is communication and clients are clients, regardless of the actual individuals writing the code.

So, how should we define these interfaces? We could think about our module and expose all the functionalities we want it to offer.

This looks like a good start, a great way to define what we want to implement in our module. Or is it? A start like this will lead to one of two possible implementations:

• A huge Car or Bus class implementing all the methods on the Vehicle interface. Only the sheer dimensions of such classes should tell us to avoid them at all costs.
• Or, many small classes like LightsControl, SpeedControl, or RadioCD which are all implementing the whole interface but actually providing something useful only for the parts they implement.

It is obvious that neither solution is acceptable to implement our business logic.

We could take another approach. Break the interface into pieces, specialized to each implementation. This would help to use small classes that care about their own interface. The objects implementing the interfaces will be used by the different type of vehicles, like car in the image above. The car will use the implementations but will depend on the interfaces. So a schema like the one below may be even more expressive.

But this fundamentally changes our perception of the architecture. The Car becomes the client instead of the implementation. We still want to provide to our clients ways to use our whole module, that being a type of vehicle.

Assume we solved the implementation problem and we have a stable business logic. The easiest thing to do is to provide a single interface with all the implementations and let the clients, in our case BusStation, HighWay, Driver and so on, to use whatever thew want from the interface's implementation. Basically, this shifts the behavior selection responsibility to the clients. You can find this kind of solution in many older applications.

The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.

However, this solution has its problems. Now all the clients depend on all the methods. Why should a BusStation depend on the state of lights of the bus, or on the radio channels selected by the driver? It should not. But what if it does? Does it matter? Well, if we think about the Single Responsibility Principle, it is a sister concept to this one. If BusStation depends on many individual implementations, not even used by it, it may require changes if any of the individual small implementations change. This is especially true for compiled languages, but we can still see the effect of the LightControl change impacting BusStation. These things should never happen.

Interfaces belong to their clients and not to the implementations. Thus, we should always design them in a way to best suite our clients. Some times we can, some times we can not exactly know our clients. But when we can, we should break our interfaces in many smaller ones, so they better satisfy the exact needs of our clients.

Of course, this will lead to some degree of duplication. But remember! Interfaces are just plain function name definitions. There is no implementation of any kind of logic in them. So the duplications is small and manageable.

Then, we have the great advantage of clients depending only and only on what they actually need and use. In some cases, clients may use and need several interfaces, that is OK, as long as they use all the methods from all the interfaces they depend on.

Another nice trick is that in our business logic, a single class can implement several interfaces if needed. So we can provide a single implementation for all the common methods between the interfaces. The segregated interfaces will also force us to think of our code more from the client's point of view, which will in turn lead to loose coupling and easy testing. So, not only have we made our code better to our clients, we also made it easier for ourselves to understand, test and implement.

Final Thoughts

LSP taught us why reality can not be represented as a one-to-one relation with programmed objects and how subtypes should respect their parents. We also put it in light of the other principles that we already knew.

ISP teaches us to respect our clients more than we thought necessary. Respecting their needs will make our code better and our lives as programmers easier.

Thank you for your time.

The Single Responsibility (SRP), Open/Closed (OCP), Liskov Substitution, Interface Segregation, and Dependency Inversion. Five agile principles that should guide you every time you write code.

Because both the Liskov Substitution Principle (LSP) and the Interface Segregation Principle (ISP) are quite easy to define and exemplify, in this lesson we will talk about both of them.

Liskov Substitution Principle (LSP)

Child classes should never break the parent class’ type definitions.

The concept of this principle was introduced by Barbara Liskov in a 1987 conference keynote and later published in a paper together with Jannette Wing in 1994. Their original definition is as follows:

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

Later on, with the publication of the SOLID principles by Robert C. Martin in his book Agile Software Development, Principles, Patterns, and Practices and then republished in the C# version of the book Agile Principles, Patterns, and Practices in C#, the definition became known as the Liskov Substitution Principle.

This leads us to the definition given by Robert C. Martin:

Subtypes must be substitutable for their base types.

As simple as that, a subclass should override the parent class’ methods in a way that does not break functionality from a client’s point of view. Here is a simple example to demonstrate the concept.

class Vehicle {
    
    	function startEngine() {
    		// Default engine start functionality
    	}
    
    	function accelerate() {
    		// Default acceleration functionality
    	}
    }

Given a class Vehicle – it may be abstract – and two implementations:

class Car extends Vehicle {
    
    	function startEngine() {
    		$this->engageIgnition();
    		parent::startEngine();
    	}
    
    	private function engageIgnition() {
    		// Ignition procedure
    	}
    
    }
    
    class ElectricBus extends Vehicle {
    
    	function accelerate() {
    		$this->increaseVoltage();
    		$this->connectIndividualEngines();
    	}
    
    	private function increaseVoltage() {
    		// Electric logic
    	}
    
    	private function connectIndividualEngines() {
    		// Connection logic
    	}
    
    } 

A client class should be able to use either of them, if it can use Vehicle.

class Driver {
    	function go(Vehicle $v) {
    		$v->startEngine();
    		$v->accelerate();
    	}
    } 

Which leads us to a simple implementation of the Template Method Design Pattern as we used it in the OCP tutorial.

Based on our previous experience with the Open/Closed Principle, we can conclude that Liskov’s Substitution Principle is in strong relation with OCP. In fact, “a violation of LSP is a latent violation of OCP” (Robert C. Martin), and the Template Method Design Pattern is a classic example of respecting and implementing LSP, which in turn is one of the solutions to respect OCP also.

The Classic Example of LSP Violation

To illustrate this completely, we will go with a classic example because it is highly significant and easily understandable.

class Rectangle {
    
    	private $topLeft;
    	private $width;
    	private $height;
    
    	public function setHeight($height) {
    		$this->height = $height;
    	}
    
    	public function getHeight() {
    		return $this->height;
    	}
    
    	public function setWidth($width) {
    		$this->width = $width;
    	}
    
    	public function getWidth() {
    		return $this->width;
    	}
    
    }

We start with a basic geometrical shape, a Rectangle. It is just a simple data object with setters and getters for width and height. Imagine that our application is working and it is already deployed to several clients. Now they need a new feature. They need to be able to manipulate squares.

In real life, in geometry, a square is a particular form of rectangle. So we could try to implement a Square class that extends a Rectangle class. It is frequently said that a child class is a parent class, and this expression also conforms to LSP, at least at first sight.

But is a Square really a Rectangle in programming?

class Square extends Rectangle {
    
    	public function setHeight($value) {
    		$this->width = $value;
    		$this->height = $value;
    	}
    
    	public function setWidth($value) {
    		$this->width = $value;
    		$this->height = $value;
    	}
    } 

A square is a rectangle with equal width and height, and we could do a strange implementation like in the above example. We could overwrite both setters to set the height as well as the width. But how would that affect client code?

class Client {
    
    	function areaVerifier(Rectangle $r) {
    		$r->setWidth(5);
    		$r->setHeight(4);
    
    		if($r->area() != 20) {
    			throw new Exception('Bad area!');
    		}
    
    		return true;
    	}
    
    } 

It is conceivable to have a client class that verifies the rectangle’s area and throws an exception if it is wrong.

function area() {
    	return $this->width * $this->height;
    }

Of course we added the above method to our Rectangle class to provide the area.

class LspTest extends PHPUnit_Framework_TestCase {
    
    	function testRectangleArea() {
    		$r = new Rectangle();
    		$c = new Client();
    		$this->assertTrue($c->areaVerifier($r));
    	}
    
    }

And we created a simple test by sending an empty rectangle object to area verifier and the test passes. If our Square class is correctly defined, sending it to the Client’s areaVerifier() should not break its functionality. After all, a Square is a Rectangle in all mathematical sense. But is our class?

function testSquareArea() {
    	$r = new Square();
    	$c = new Client();
    	$this->assertTrue($c->areaVerifier($r));
    }

Testing it is very easy and it breaks big time. An exception is thrown to us when we run the test above.

PHPUnit 3.7.28 by Sebastian Bergmann.
    
    Exception : Bad area!
    #0 /paht/: /.../.../LspTest.php(18): Client->areaVerifier(Object(Square))
    #1 [internal function]: LspTest->testSquareArea()

So, our Square class is not a Rectangle after all. It breaks the laws of geometry. It fails and it violates the Liskov Substitution Principle.

I especially love this example because it not only violates LSP, it also demonstrates that object oriented programming is not about mapping real life to objects. Each object in our program must be an abstraction over a concept. If we try to map one-to-one real objects to programmed objects, we will almost always fail.

The Interface Segregation Principle

The Single Responsibility Principle is about actors and high level architecture. The Open/Closed Principle is about class design and feature extensions. The Liskov Substitution Principle is about subtyping and inheritance. The Interface Segregation Principle (ISP) is about business logic to clients communication.

In all modular applications there must be some kind of interface that the client can rely on. These may be actual Interface typed entities or other classic objects implementing design patterns like Facades. It doesn’t matter which solution is used. It always has the same scope: to communicate to the client code on how to use the module. These interfaces can reside between different modules in the same application or project, or between one project as a third party library serving another project. Again, it doesn’t matter. Communication is communication and clients are clients, regardless of the actual individuals writing the code.

So, how should we define these interfaces? We could think about our module and expose all the functionalities we want it to offer.

This looks like a good start, a great way to define what we want to implement in our module. Or is it? A start like this will lead to one of two possible implementations:

• A huge Car or Bus class implementing all the methods on the Vehicle interface. Only the sheer dimensions of such classes should tell us to avoid them at all costs.
• Or, many small classes like LightsControl, SpeedControl, or RadioCD which are all implementing the whole interface but actually providing something useful only for the parts they implement.

It is obvious that neither solution is acceptable to implement our business logic.

We could take another approach. Break the interface into pieces, specialized to each implementation. This would help to use small classes that care about their own interface. The objects implementing the interfaces will be used by the different type of vehicles, like car in the image above. The car will use the implementations but will depend on the interfaces. So a schema like the one below may be even more expressive.

But this fundamentally changes our perception of the architecture. The Car becomes the client instead of the implementation. We still want to provide to our clients ways to use our whole module, that being a type of vehicle.

Assume we solved the implementation problem and we have a stable business logic. The easiest thing to do is to provide a single interface with all the implementations and let the clients, in our case BusStation, HighWay, Driver and so on, to use whatever thew want from the interface’s implementation. Basically, this shifts the behavior selection responsibility to the clients. You can find this kind of solution in many older applications.

The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.

However, this solution has its problems. Now all the clients depend on all the methods. Why should a BusStation depend on the state of lights of the bus, or on the radio channels selected by the driver? It should not. But what if it does? Does it matter? Well, if we think about the Single Responsibility Principle, it is a sister concept to this one. If BusStation depends on many individual implementations, not even used by it, it may require changes if any of the individual small implementations change. This is especially true for compiled languages, but we can still see the effect of the LightControl change impacting BusStation. These things should never happen.

Interfaces belong to their clients and not to the implementations. Thus, we should always design them in a way to best suite our clients. Some times we can, some times we can not exactly know our clients. But when we can, we should break our interfaces in many smaller ones, so they better satisfy the exact needs of our clients.

Of course, this will lead to some degree of duplication. But remember! Interfaces are just plain function name definitions. There is no implementation of any kind of logic in them. So the duplications is small and manageable.

Then, we have the great advantage of clients depending only and only on what they actually need and use. In some cases, clients may use and need several interfaces, that is OK, as long as they use all the methods from all the interfaces they depend on.

Another nice trick is that in our business logic, a single class can implement several interfaces if needed. So we can provide a single implementation for all the common methods between the interfaces. The segregated interfaces will also force us to think of our code more from the client’s point of view, which will in turn lead to loose coupling and easy testing. So, not only have we made our code better to our clients, we also made it easier for ourselves to understand, test and implement.

Final Thoughts

LSP taught us why reality can not be represented as a one-to-one relation with programmed objects and how subtypes should respect their parents. We also put it in light of the other principles that we already knew.

ISP teaches us to respect our clients more than we thought necessary. Respecting their needs will make our code better and our lives as programmers easier.

Thank you for your time.

Another chance to catch the most interesting, and important, articles from the previous week on MIT Technology Review.

Penetration testing: Accurate or abused?

DB Networks Helps Prevent High-Profile Customer Data Breaches With Network Behavioral Analysis and Continuous Monitoring of Databases

Having a bad development workflow will cost you a lot. It can make your senior engineers be productive like juniors, or even worse push them to leave the company. A great workflow can make push your good developers to be great and your best to be exceptional.

Getting this workflow in order is one of the most critical steps any business and team can take.

Two best practices that have gained a lot of traction over the last years are Continuous Integration and Continuous Deployment.

Continuous Integration is the practice of testing each change done to your codebase automatically and as early as possible. But this paves the way for the more important process: Continuous Deployment.

Continuous Deployment follows your tests to push your changes to either a staging or production system. This makes sure a version of your code is always accessible.

First, let us have a look at Continuous Integration. I’ll show you how to get started with testing. Later we will talk about Continuous Deployment which is the next logical step and will increase efficiency of your development team tremendously.

Continuous Integration

Every step in your development workflow that can be automated should be. You need this automation to be able to focus all your time on building your product and providing value to your customers. Testing is one of those steps where automation is key.

Automated testing allows you to implement new features quickly, as you can always prove that your most important features still work as you expect. This gives you the confidence to experiment.

How to start testing software

When starting testing your software it’s important to view the app from a user’s perspective. Let’s have a look:

• What are the typical workflows?
• What features do users go through often?
• What steps do users go through often?

Get started with Selenium, PhantomJS or other frontend testing tools to make sure your application works as expected from the users perspective. Move from testing the user interface to testing lower level code, not the other way around.

Often teams struggle with defining those first important test cases. We’ve come up with a guide on how to start testing, so take a look and see if this works for your team as well.

Tools you can use to start testing your frontend:

• Jasmine (JavaScript)
• Selenium (Frontend Testing)
• CasperJS (Frontend Testing)
• Cucumber or Lettuce (Behaviour Driven Testing for Ruby and Python)

Now that we have a strong base of tests let’s go into lower levels and start with Unit-Testing. We want to make sure that the workflows are fine and that our UI works. With every change!

You have the tools, you know how to do it. Now the most important thing is: Get started with testing! It pays off immediately, not just from a software development perspective. You can read about the business advantages of Continuous Integration in this blog post by Joe Green.

Continuously running your tests

It’s too easy for us as developers to say that a specific change won’t break something and later realise it did break the app. Often we are simply too lazy to really run all of our tests. This is where an automated system that runs or tests whenever we do any changes continuously can help us from falling into the trap.

Oftentimes teams work on 2 week or even longer sprints. At the beginning of the sprint a developer pushes some changes that breaks a test. The team doesn’t have continuous integration, so nobody detects the error for a week. At the end of the sprint, before deploying to production, the lead developer runs all tests on a test machine to make sure everything is fine. And only at this point does the team detect the failed test. Now going back and determining which change broke the test is hard and takes a long time, totally unnecessarily. The failing test could have been detected only minutes after it was pushed, but as there was no automated system in place the team wasted precious time late in the sprint, instead of fixing it early on.

The longer the sprint, the more costly this cycle becomes. This workflow doesn’t help the team, the single developer and especially not the company. Relying on automation to tell us early on when something goes wrong needs to be at the core of your development workflow.

Continuous Integration is the first, but very important step in Continuous Deployment.

Have a look at Martin Fowler’s in-depth article about Continuous Integration to learn more about it.

Continuous Deployment

Code rots. It should always run somewhere. There are a lot of changes that can break your app without you realizing it. Think about external dependencies being updated, API’s changed, server packages installed… The list goes on. Often we do not have the ability to control every part of our infrastructure. We rely on other products and companies to maintain parts of our stack.

This is where Continuous Deployment shows all of it’s power. Whenever your main code branch passes the tests it should immediately be deployed to at least a staging environment. Even better if you can go to production immediately. With the master branch running at least on staging you can always have your QA or development team take a look or even use this last version. This shortens the cycle until you find an error or usability problem tremendously.
It moves finding those problems very early into the lifecycle, where it is cheap to fix them, instead of late where you often can’t fix them any more.

Configuring a deployment pipeline

Deployment pipelines describe how a change in your application moves through your infrastructure into production. It lays out all necessary automated and manual steps. Every step that can be automated should be, to make the deployments as productive as possible.

Having this predefined workflow pipeline in place will make sure you follow all the necessary procedures when you have to ship a fix quickly. A small mistake could mean a downtime, so relying on automation is crucial for this.

The ability to ship, get feedback from your customers and iterate on your product quickly is a major competitive advantage. Intercom wrote a blog about why shipping is your companies heartbeat. Especially when building the first iterations of your product the importance of shipping quickly and regularly can’t be overstated.

Today, as the costs for creating and publishing software shrunk dramatically, it is vitally important to get your product to your customers quickly. Your competition has the same cheap and productive tools available. Getting the most out of your workflow and push your productivity to the next level is how you can differentiate. Continuous deployment can help you make this happen.

Getting started

We’ve identified several steps that can help you get started with continuous deployment. These steps have come out of interviews with dozens of companies and constant feedback from the thousands of developers using our product.

Test everything, but in a smart way

Automation is the key to pushing your productivity. Testing a vital step to automate all your quality control. Whenever you want to change your product you need to be able to quickly and automatically assess that everything still works. Getting to this point assures you can iterate and innovate quickly without having to worry about breaking things. It allows to push much farther than you were ever able before.

Tests are first and foremost a tool to keep your users happy. You don’t put effort into testing to make your development team happy or fulfill some vague workflow, but to be sure that you don’t break stuff your customers use. And additionally also to be able to implement the next features they want and pay you for. So start testing with the user in mind. Start testing the Frontend and interactions there first, before moving to lower level tests. Remember we test to make our users happy, not just to create better software.

Tests make software as Clemens laid out in his blog post.

Example

This script tests that when entering good day into google translate it is properly translated from german into english.

With CasperJS you can start testing your front-end quickly and move to more complex scenarios later.

Automate Deployment

Every step in your deployment has to be automated. There can’t be any manual steps involved, as you will fail to do them once, which will kill your application. As you are aware you automatically start deploying less often. This creates a vicious cycle where the less you deploy the worse your deployment infrastructure becomes. Continuous Deployment works because of automation, so make sure you invest enough time here.

Automate Rollback

Automating rollbacks is critical when pushing regularly. Otherwise you will always fear to push more. Rollback includes your application code but also your database. Regular backups are an absolute must. Try to restore them regularly as well, otherwise you will never be sure if it really works until you desperately need them.

Deploy to Staging

Automatically push your master branch into a staging application. The staging application is your first line of defense, so you can easily review any changes going into production. This can even include automated tests, so you know your staging server works fine.

Use your staging environment

Using your own product is incredibly helpful to determine problems in your application. While using your production server is fine, using your own staging system is even better. It makes sure that you immediately detect errors that might take down your application, as you team always uses the latest available codebase.

Automatically deploy to production

Finally deploy continuously to your production environment. This workflow will dramatically change the way your whole organization thinks about releasing software. It is not just a little faster deployment, but needs to be planned and included in your daily work and planning. It’s been an important part in the innovation of some of the largest tech companies in the world and you should give it a trie too.

Conclusions

Finding new ways to become more productive is important for every software team. Getting slower, especially in comparison to your competition, could easily harm or even kill your company and product. You want to be able to push quickly and regularly to your customers, so they get the best product possible. Continuous Deployment can get you a long way there.

If any questions come up or if there is anything else we can help let us know either here in the comments or send us a tweet to @codeship. We’ve also recently released a free ebook that walks you through our development workflows and can help you dive deeper into Continuous Deployment. You can grab the book here.

Ship long and prosper!

Relevant links and further information

• Introduction to Continuous Integration by Martin Fowler
• Why Continuous Deployment by Eric Ries
• Continuous Delivery by Jez Humble
• A Business Case for Continuous Integration
• How To Start With Testing From Top To Bottom
• Start Testing Your Website With CasperJS
• The Codeship: A hosted Continuous Integration and Continuous Deployment Platform
• The Codeship Blog about Continuous Deployment, Continuous Integration and Software Testing
• Codeship’s Free Ebook: Efficiency in Development Workflows

The post Why You Should Use Continuous Integration and Continuous Deployment appeared first on Treehouse Blog.