I work for a small development company, 20 people total in the entire company, 3 in actual development, and we've adopted CD for our commits to trunk, and it works great, from a code management and up-time side. However - we're getting flak from our support staff and marketing department that they don't feel that they're getting enough lead time on new features and notifications on bug fixes that could change behavior. Part of why we love the CD system is for us in development, it's fast, we fix the bug, add the quick feature, close the Bugz and move on with our day to the next item.

All members of our company are now on HipChat at all times, and when a deployment occurs, a message is sent to a room that all company members are in, letting them know what was just deployed (it just shows the commit messages from tip back to the last recorded deployment). We in development are also attempting to make sure that when we're making a change that modifies the UI or a public facing behavior, we post a screenshot to the All Company room and explain what the behavior change is, seeking pushback or concerns. Often, the response is silence. Sometimes, it's a few minor questions, but nothing that need stop the deployment from happening.

What I'm wondering is how do other users of the CD method deal with notifications of new features and changes to areas of the company that are not development - and eventually on to customers in the world?


  • Did you consider posting details of work in progress? Things that are not being deployed but will be soon? – Oded Sep 11 '12 at 20:39
  • That's exactly what I'd like to know how to do, I think - but I don't want to constantly stop to announce to everyone "I'M GOING TO DO THIS NOW"...."I'M NOW DOING THIS"...."I'VE DONE DOING THAT". Most of it is me being lazy... but some of it is really a concern that at some point I'm making more noise than signal, and killing my productivity at the same time. – Francis Spor Sep 11 '12 at 20:45
  • 1
    Having a project plan and sharing it with the company would be a good start. Something with planned changes and their progress along side a timeline. – Oded Sep 11 '12 at 21:03
  • We do a project plan on large feature requests, but it seems most of our development is immeadiate minor feature requests from support for customers or minor bug fixes, generally found in our legacy code base that we haven't had time to rewrite yet. How would the "bug fix of the instant" be best communicated? – Francis Spor Sep 11 '12 at 23:03
  • Can your bug tracking system send alerts to watchers when a bug is fixed? It would be noise to everyone else. – MebAlone Sep 12 '12 at 9:20

Your problem isn't one of communication of changes and isn't one of a poor execution of CD, it is fundamentally a problem of the current structure of your company, and one of developer fanaticism.

Organizations that LIKE Continual Delivery

Much like with people, companies can lean Conservative and Liberal. No I am not talking politics, just a fundamental way that day to day business is viewed and looked at. Liberal companies tend to be open to communication and the inflow of information. They thrive on it. They are more excited about change and see adaptability as opportunity. They tend not to care for following strict processes and can suffer from wild swings in stability and solvency.

Companies that are more conservative are very good at having a specific business objective in mind and achieving their goals in a careful methodical process driven way. Rapid influx of information can be daunting and sometimes threatening. Stability and predictability are more important than being cutting edge and experiencing the latest and greatest. They are good at finding a niche and tenaciously protecting their market positions. They tend to be more stable and consistent in performance.

Liberal companies like startups that are getting off the ground are much more interested in Continual Delivery because it gives them the latest information about progress immediately. They don't have a stable source of funding and fierce competition means that time can be even more valuable than money. Continual Delivery ensures that there is no wasted time from the business perspective when the opportunities for growth are endless.

Conservative companies will ignore CD at best and be annoyed or threatened by it at worst. Their management culture formed as a result of a successful business venture that ensures a steady stream of income. They frown on unnecessary change as it could be risky, introduce new bugs, and the benefit can sometimes be null. It may not matter if the user is any happier with your new features if you already have the users company locked into a service agreement or contract. The money is separate from the quality of the software at this point.

Your company doesn't seem to understand it because perhaps their business model and customer base lend them to lean conservative and fear the constant change that is implied by CD.

Developer Fanaticism and missing the big picture

They may not understand why you even are motivated to achieve this, and to be honest I don't either.

  • Is it something that you wanted to pad your CV with?

  • Is it a misguided attempt to organically change the culture of the company from within?

  • Is there a specific misunderstanding or tension between Customer Support and Development that you are hoping to solve?

This you will have to figure out for yourself. Ultimately though I come to these conclusions about your company by the fact that it seems the Developer Group in your organization needs to "win over" Customer Support on this thing. In a Developer centric organization that is open to change, opportunity and continuous improvement, the Developer group will set the rules and standards and customer support will have to adapt to you.

In the end I am not saying that CD is a bad thing by any means, but it won't benefit your organization. Customer support would ideally be happy to do nothing but order bug fixes from the Developer group as needed like the drive-thru at a fast food restaurant.

| improve this answer | |
  • Sadly, I think you're right. We're going to go with a mixed model for right now - bug fixes deployed instantly, in our current CD methodology, features built in branches that will remain unmerged until everyone who needs to sign off is either silent for a period or has their shot at doing what needs to be done. Thanks so much for your input an ideas. – Francis Spor Sep 13 '12 at 13:12

The best way to keep everyone in the loop is to have a set production deployment day/time on a reoccurring basis. Then you can send out a notification to all affected employees a list of all changes that will be implemented with the next deployment. This should be sent out well in advance of the changes being deployed (I would say at least an 8hr notice for non break-fixes), and preferably at the same time every cycle so all users know when they have to look for upcoming changes. Asking users to be continually aware of a chat-room message or up to date on their email at all times every day is unreasonable.

On a side note it sounds like there is not staging/QA step in your process, if this is true you should add one, otherwise you are sitting on a time bomb.

| improve this answer | |
  • Isn't that antithetical though to the philosophy of Constant Deployment/Delivery? The idea is code that is written is well tested using automated tools and deployed, and if it breaks on server, you fix it, quickly, and then the fix gets deployed. There is no "deployment", rather a series of changes throughout the day - link. Just feels like an eight hour lead and a staging environment would make that process very hard. – Francis Spor Sep 11 '12 at 23:01
  • 1
    @FrancisSpor, it sounds like your development folks like CD but you haven't done a good job of selling it to the rest of your organization. People supporting things in production like stability & predictability. IMO you should consider adding a QA/staging layer like Ryathal mentions, deploy as you do now to that and publish notices like you do now, then deploy QA/staging to production say once a day. – DaveE Sep 11 '12 at 23:58
  • That may well be true. However, I'm sorta hoping that someone with experience with CD in their environment will share their experience encompassing more of the various departments of their company into their release system. – Francis Spor Sep 12 '12 at 1:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.