0

The company is thinking about introducing a proper version control/source control.

Within this process is considered an idea to introduce a regular date for deployment to production, for example every Tuesday. Before, for years, every programmer deployed his changes to production when they were ready and tested.

Are there any benefits in a regular deployment date?

This is non-IT company with Salesforce department. Admins and devs are making ad-hoc fixes, there is no any solid development work going, ie there is almost no chance that two people will intersect working on the same piece.

Improve this question
7
  • This is an opinion based question so doesn't fit well here. That said, for me, there is little point in artificially delaying fixes, or artificially hurrying people to resolve issues (doing this latter is likely to lead to cutting corners and making mistakes so hurts the user's in the end). I do, however, recommend two things: 1. Coordinated releases (on an as-needed basis) notified before it happens so everyone knows what is coming. 2. Use of unlocked packages instead of "(un)happy soup" and change sets for the majority of metadata.
    – Phil W
    Jul 5, 2022 at 6:00
  • @PhilW I've used agile a lot, it works well. You don't "hurry" people or "delay" bugs, those are both bad things, but establishing a cadence turns a development marathon into more manageable pieces.
    – sfdcfox
    Jul 5, 2022 at 6:06
  • I was talking about delivery being flexible not creating marathons. We use agile for our product development and simply deliver when it makes sense rather than to a clock. And, by the way, delivery doesn't change whether it feels like a marathon or not; that is quite separate IMHO.
    – Phil W
    Jul 5, 2022 at 6:23
  • Like I said, this is opinionated ;)
    – Phil W
    Jul 5, 2022 at 6:26
  • @PhilW There's actually a lot of empirical evidence out there if you're willing to look. A question like this doesn't need to be opinionated, there's lot of research out there that explains why (or not) regular release cycles are good.
    – sfdcfox
    Jul 5, 2022 at 6:32

1 Answer 1

Reset to default
1

"Scheduled Deployments" have almost no benefits, but lots of downsides. Notably, there's no distinction between bug fixes and feature releases, it will cause undue periods of stress and wasted workhours, bugs will be plentiful, and it will generally just be a mess.

However, once you start talking about "scheduled version releases", now you have something to work with. A version is a collection of features all released at once. By using the version ideology, you can actually improve the number of bugs that are caught before deployment to production, make it easier to identify which version introduced a given bug, and provide product stability for users in-between releases.

In this case, you'd have a regularly scheduled release every few weeks or months that contain many new features, which have all ideally been through QA and UAT (User Acceptance Testing). These extra steps that you apparently lack in your current lifecycle are important, and you shouldn't be skipping them.

Also, by going with a "version" route, you can test that you're not introducing bugs that can only be found by end-to-end testing. You could still use hotfixes if you need to, but hopefully with better QA/UAT, they would be rare.

So, in summary, as part of a comprehensive software development lifecycle strategy, scheduled feature releases drastically reduce the number of bugs and improves the quality of the product.

Improve this answer

Not the answer you're looking for? Browse other questions tagged .