sdlc

I have a few questions around how do you handle testing and deployment when many developers are working on the same thing (that cant be split further) and you still want to deploy daily. Currently we follow Gitflow where we have our features branches that everyone is working on an isolated feature. Features are merged into develop branch. Every now and then we take some time to cater for user requirements / bug fixes / quick features etc. The end goal is to get those to PROD asap. My question is what process would you suggest such that: 1) We can deploy without introducing bureaucracy (e.g.

I believe that Agile is nothing but another implementation of Spiral Model. I am a big supporter of Spiral (The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts) since its beginnings and have seen that lot of projects implement Spiral without knowing that they are operating in a Spiral world. Since the day Agile started gaining popularity the concept of spiral started getting overlooked a little bit. I am sure that for complex projects spiral is still the best

What is the difference between Scrum and Agile Development? Are Sprint and Iterations the same? Sindico Scrum is just one of the many iterative and incremental agile software development methods. You can find here a very detailed description of the process. In the SCRUM methodology, a Sprint is the basic unit of development. Each Sprint starts with a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made. A Sprint ends with a review or retrospective meeting where the progress is reviewed and lessons for the next sprint are

Some of the projects we're working on have strong roots in jQuery 1.4.2 or earlier, and somewhere between lacking the performance edge (or syntactic sugar) of the latest releases, the humiliation of using now-deprecated methods, and the discomfort of deploying a 3+ year old version of an actively maintained library, an upgrade is now imminent. What are some practices popular in the community that we could adopt/re-visit to ensure a smooth rollout (i.e. focus on obscure compatibility issues, picking up global regressions, re-factoring some of the older code...)? How would they be best

My question is, which version-naming scheme should be used for what type of project. Very common is major.minor.fix, but even this can lead to 4 number (i.e. Firefox 2.0.0.16). Some have a model that odd numbers indicate developer-versions and even numbers stable releases. And all sorts of additions can enter the mix, like -dev3, -rc1, SP2 etc. Exists reasons to prefer one scheme over another and should different type of projects (i.e. Open Source vs. Closed Source) have different version naming schemes? There are two good answers for this (plus a lot of personal preferences, see gizmo's