[bobsy]

With my employer we deploy several times a day. We have 2 SVN repos. One dev, one live. To make a change live you commit your change to the live repo and it is auto-synced. I am not sure how we came to have this. When I first joined there was a code reviewer who manually pushed changes live. He quit and the server admin made it auto.

I wouldn't recommend this set up. I am incredibly competent. I make maybe 1 minor mistake a month - if that - so with me this set up is workable. The other developers I work with.. not so much. The main issue with this set up is newbie developers deploying what they thing is a good fix which breaks in lots of edge cases. Bad patches like that can take weeks to become apparent then longer to chase out of the system as there is no way to simply rollback.

For my side project I deploy every Wednesday. Every now and again there is a bug fix which needs to be slipped in on an odd day. I currently deploy manually because I haven't set anything else up.

Throw up maintenance page -> update database -> upload new files -> quick test -> remove maintenance page.

It is a bit time intensive but I haven't had any problems with it yet. I like to group changes so I can announce them on the same day.

[wrath]

At my company I tend to think that we hire very competent developers. Our code base is so complicated (because of legacy code and/or the complexity of the tasks) that developers make mistakes all the time. They are caught by both a peer code-review process and the QA team or support/customers. I trust that you are "incredibly competent" but 1 mistake a month seems very low to me. But what do I know! :)

What type of product do you have? Do you have a QA team? Do you track new and close bug counts from week to week? Similarly do you track regression counts from build to build? Does the code base have a high completeness rate for unit tests? Do you only deploy if you pass the unit tests? What if you introduce a bug that screws up the data, do you have a fallback strategy?

I'm curious because I always had a dream to be able to deploy on a daily basis but I've never gotten there "yet". It's always nice to hear what others are doing for daily deployments.

[bobsy]

> I trust that you are "incredibly competent" but 1 mistake a month seems very low to me. But what do I know! :)

Honestly, I don't know where "incredibly" came from. I was going for pretty (pretty competent). I think my mind was in 2 places at once.

I have been working with the same code base for 2 years. I know it back to front. I am good at testing and my mind is open to the various scenarios which need to be tested for each change which is made. I make mistakes all the time but they very very very rarely sneak out and get live.

> What type of product do you have?

Its a website-as-a-service product.

> Do you have a QA team?

Nope. For major features we try to get all employee's to pitch in for a group test on a development server. That is the best we do. Minor features / fixes are just tested locally by the developer then go out.

> Do you track new and close bug counts from week to week?

We use bug tracking software. We track the amount of open bugs. When I started I was getting around 20 bugs / developer support requests a week. Now I get one or two. Most of what I get through the tracker is trouble shooting unfamiliar hosting configurations.

> Similarly do you track regression counts from build to build?

No

> Does the code base have a high completeness rate for unit tests?

The code base doesn't have unit tests. It was built by a hobbiest 4 years ago. The current version supports legacy features from a previous version. It is mainly procedural with a smattering of random classes. There is a lot of code duplication. It is the definition of spaghetti code.

Basically, the core software needs to be rewritten. This isn't a management priority so we make do.

> Do you only deploy if you pass the unit tests?

N/A

> What if you introduce a bug that screws up the data, do you have a fallback strategy?

We have twice daily backups and can rollback.

[singular]

"I am incredibly competent. I make maybe 1 minor mistake a month - if that"

https://en.wikipedia.org/wiki/Dunning-Kruger

[anton_gogolev]

Two questions.

1. Why bother with two SVN repos? 2. Any specific reason for SVN at all (large files, binary files, non-technical users)

[bobsy]

1. I wasn't around when the system was set up. I think the idea was that developers could work together on an incremental version in dev repo. Then it could be pushed out as a clear update in the live repo.

2. It was what someone chose 4 years ago. The guy has since left. Everyone is familiar with SVN. SVN is pretty easy to get into. We haven't seen a need to change.

[pcowans]

So, obvious question... why do you not have tests in this set up?

[bobsy]

I answered this above.

The code base doesn't have unit tests. It was built by a hobbiest 4 years ago. The current version supports legacy features from a previous version. It is mainly procedural with a smattering of random classes. There is a lot of code duplication. It is the definition of spaghetti code.

Honestly I wouldn't know where to begin with unit tests in this code base.

[aidos]

Out of interest, how big is the team?

[bobsy]

3 developers, 1 server admin, 5 other who do marketting, design, etc