1. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2011
    Rep Power

    Product / Code Release


    I work on the Product team in our company, and we have our Dev team outsourced to an agency in another country. Our company is growing at a significant rate (1000 new users oer day, increased revenue and employees) yet, the Dev team is becoming more and more of a problem:

    - constantly missing new product deadlines
    - take weeks to fix or adjust small things (which sometimes are literally a case of changing one simple CSS value)
    - they will only publish code once every 2-3 weeks
    - every time they publish code, we (the Product team) spend the next few days reporting bugs, highlighting the lack of attention to detail, and all of the problems that come with each release of code
    - when we ask a question, it takes at least 24hrs for a reply

    We've tried changing the processes on numerous different occasions, yet they continue to let us down each time, and their quality is sub standard.

    We are now working with the company to bring some of their dev team in house into our company, so we can work hands on with them, along with instant communication, and then hire around them.

    I have a question which I hope someone can help with.


    How often should a company push code? I know if depends on the setup, etc... but I read about companies pushing code every day, and even hour. How does a company who is pushing code once every 3 weeks, change so they can push at least once a day?

    Thanks in advance to anyone who can help with this.
  2. #2
  3. Wiser? Not exactly.
    Devshed God 2nd Plane (6000 - 6499 posts)

    Join Date
    May 2001
    Bonita Springs, FL
    Rep Power
    How often you push code comes down to what kind of policies you have in place and what is possible for your environment.

    How do you test new changes?
    Do you have automated testing or does it have to be done manually? Do you test everything or just areas you think were changed?

    Companies that push frequently generally will have automated unit testing so that after a change they can just run the test suite and make sure everything is good. They also have confidence that a successful test run means everything works because the test suite covers all aspects of the application.

    The less automated testing you have in place, or the lower your confidence in said testing, the more time you'll have to spend doing manual testing which means pushing updates less frequently. Since manual testing may be time consuming also you don't want to be doing it after every tiny change, instead you'd batch your updates and test then release at some sort of milestone.

    How do you handle a failure?
    Say you push an update and suddenly everything is broken? What if not everything broke but just some small but still important part of things? How do you recover and how long does that take? What's the impact on your users?

    If you have the ability to rollback a change nearly instantly then pushing code often is less risky. If it'd take hours to revert the update then you'll need more time and testing to ensure nothing goes wrong.

    Not all changes can be rolled out asap
    Some changes might require significant updates that require some amount of down time. Such changes need to be scheduled and handled with care, not just pushed whenever they are done. For example an update might require modifying your database structure and migrating existing data from the old structure to the new structure. That migration might take some time if you have a lot of data.

    So to get more directly to your question, How does a company who is pushing code once every 3 weeks, change so they can push at least once a day?
    Develop policies and procedures that support that goal and enforce them.

    Do you have extensive automated testing? If not, add it.
    Do you trust the testing you do have 100%? If not, improve it until you do
    Do you have solid backups and the ability to revert changes quickly? If not, develop the capability to do so

    Finally, remember that just because you can push changes out quickly doesn't mean you always should. Evaluate the impact of changes and determine if they something you can push quickly or would be better done during a scheduled maintenance window.
    If I helped you out, show some love with some reputation, or tip with Bitcoins to 1N645HfYf63UbcvxajLKiSKpYHAq2Zxud

IMN logo majestic logo threadwatch logo seochat tools logo