Search

Continuous Delivery - Part 7 - Cultural Change

Updated: May 5


In order for continuous delivery to work the organization has to go a cultural change and switch to Dev-Centric Culture.


Continuous delivery gives a lot of responsibility in the hand of the developer and as such the developer need to have a sense of ownership. At Wix we say that it is the developer’s responsibility to bring a product / feature to production, and he is responsible from the feature inception to the actual delivery of the product and maintaining it on the production environment.


In order to do that several things have to happen.


Know the business:

The developer has to know the business and be connected to the product he is developing. By understanding the product the developers makes better decisions and better products. Developers are pretty smart people and they don’t need to have product specs in their face (nobody actually reads them). Our developers work together with the product mangers to determine what the product for the feature should be. Remember while the actual product may have several features bundled together for it to be valuable for the customer, we develop per feature and deploy it as soon as it is ready. This way both the product manager and the developer get to test and experience each feature on production (it is only exposed to them via Feature toggle) and determine if it is good enough, and may cause the direction of the product to change not according to plan, and actually develop a different next feature than the planned one.


Take ownership

Developers are taking ownership on the whole process, which means that they are the ones that need to eventually deploy to production. This statement actually changes the roles of several departments. What the company needs to do is to remove every obstacle in the developers way to deploy quickly on his own to production.


The operations department will no longer be doing the deployments. What they will do from now on is to create the automated tooling that will allow the developers to deploy on his own. Operations together with dev will create the tooling to make the production environment visible and easy to understand to developers. Developers should not start a shell console (ssh) in order to view and know what is going on with the servers. We created web views for monitored metrics of both system and application metrics and exceptions.



BI and monitoring need to no longer create an on-demand reporting. They now need to enable real time KPI monitoring available and trigger alerts on any suspicious change especially post deployment.


QA department will stop doing manual QA, and start writing end to end automated tests. At Wix we initially had QA helping the server developers writing IT tests, however after about a year where we had a server QA we decided that we are proficient enough and well covered in automated tests that we do not need QA for the server side. We still use QA on the client side development (i.e. UI), they do both automated and manual testing.


Team leads need to give a lot of freedom to the developers and help remove obstacles from their path to deploy.


Product We trained our product managers to think lean and feature centric and mandated that every feature is A/B tested. Developers and product managers sit in the same room and discuss the product during the whole development cycle. Today product managers open and close tests and feature toggles dozens of times a day and no longer assume they know what the users want, everything is tested.


Created a CI team that will develop the CI tooling and automate the staging environment creation. Today we can create staging environment with any version and install what ever services we choose with just a click of a button.


The most important change is actually going to Test Driven Development. No feature is considered production ready unless it is fully tested . Product managers, developers and management understand the importance of automated testing and we take that under consideration in our time estimates. We invest a lot in testing and always improving our testing framework.


< Part 6 - Backward & Forward Compatibility Part 8 - Deploying To Production >