We’re rewarding the question askers & reputations are being recalculated! Read more.
53

This question is really two questions in one. Todo comments Of all the ways to track action items, this is the worst. TODO comments are good during active work or as a way of suggestion to a maintainer, "here is something that could maybe be improved on in the future". But if you rely on TODO comments for getting work done, you're doomed to fail. What ...


45

Your build number won't be reset to 0, when minor and major versions increase, this violates sections 7 and 8 of the specs: Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if ...


29

my years of software development experience suggest that in practice it can't work. Have you tried it? Dave and I wrote the book based on many collective years of experience, both of ourselves and of other senior people in ThoughtWorks, actually doing the things we discuss. Nothing in the book is speculative. Everything we discuss has been tried and tested ...


28

Personally, I choose option 3: keep versioning information in VCS metadata, specifically, tags. Git makes it very easy to do so, because there is a command git describe, which can uniquely describe a commit based on a tag. Here's how it works: If the current commit is tagged, output the name of the tag. Otherwise, walk the history backwards until you find ...


24

Do not use TODOs. You already have a TODO list in your project. It's called the issue tracker. I think the real problem is in this sentence: we can create a ticket in our issue management system, which creates clutter and also might get moved to a later sprint or the backlog by management. If your issue tracker creates to much clutter, find ways to fix ...


17

Traditionally, before Continuous Integration, Continuous Build, Continuous Deployment, Continuous Testing, etc., the system was split into modules and those modules were developed by independent teams which didn't interact very much. The term "integration" refers to the event when those independently developed modules were assembled together into the ...


14

I take a different view from the other answers on here already. I agree with you that you want to integrate changes from developers as soon as possible, and to keep testing the combined mix of code. However, I do not agree that its right to ship code developed this morning, just because we are releasing this afternoon. That is a recipe for disappointed ...


11

First, CD takes one big mental adjustment -- you have to admit that sometimes things will go out broken no matter what you do. At the end of the day, you cannot prove a negative. Once you get past this, you realize that you need tools and procedures to a) catch these errors very quickly and b) either roll back or deploy the update very efficiently. Moreover,...


10

Usually the developer runs them manually before checking in, and a CI server runs them automatically after checking in. Programmers are usually pretty good about running unit tests for incremental builds on the configuration they've been working on, but they don't do things like do a clean build from a completely clean checkout from version control, run ...


9

Continuous deployment or continuous delivery is very common in web services and SaaS apps. Amazon, Facebook, Github, Google...they're all deploying all the time. Some operators deploy a handful or even dozens of updates a day for each very narrowly-defined service. I'm not even sure you could easily count the number of deployment events massive shops like ...


9

What I'm looking for is a way that a TODO comment can have a deadline against it, and our Continuous Integration system (current undecided which we'll use) would reject the build if this deadline was expired. What your asking for is doable if you're willing to do the work and follow through. // TODO by v55: Create migration to move constraints to new ...


9

I write some code, then I build it (compile it) then I run the tests. This happens on my local machine. That's the "code & build" phase in that diagram. Then I check my code in to a central repository, triggering a remote build and remote testing. I have now performed a "doesn't just work on my machine" test. I've "integrated" my code into a central ...


8

In short: Since you don't know whether a build contains a critical bug at the time of deployment, you may need to roll back more than one version when you're deploying at a relatively high frequency. If your setup doesn't allow you to do so, your only alternative is to roll forward as quickly as you can. As soon as you have an application that has 3rd party ...


8

Yes. It is good practice to keep most of the version number in vcs. If we consider semantic versioning semver.org where we have major.minor.patch.build the first three must live in vcs. The last one can be a incrementing number from your build server used to backtrack the specific commit that a binary is made from. To facilitate this in .NET we have made a ...


8

When a code change A is rejected, don't think necessarily in terms of "rollback feature A by undoing the merge using SCCS". Think in terms of "adding a new change to the code which fixes the defects found by QA". Depending on the issue, this can mean: fixing a bug immediately, but leaving the code of A in master disabling the functionality added by A (by ...


8

The difference is the data. A UAT environment is set up for "user acceptance" of new functionality. In order to test that functionality, QA or stakeholders may set up user profiles a particular way in order to exercise particular features, or may set up mock products or configurations to check them all out. A staging environment is often set up with a ...


8

Quality gates – checks that must pass before some changes can be merged – are a useful way to detect quality problems early. These gates can include any kinds of quality checks, including running test suites or using static analysis tools. The idea is that finding and fixing problems early is much easier (and therefore cheaper) than having to debug changes ...


7

Typically you have multiple pipelines - you run "quick n dirty" unit tests as devs commit changes. When they say they're ready to merge their changes into a testing branch, you run a more "slow n steady" integration tests (and any other analysis tools you like). If these pass, you merge the testing branch onto some QA branch where you can generate deliveries ...


6

There are two problems here: one is implementing half a feature; the other is keeping the shipping product working during continuous development. Implementing half a feature A strong overarching design will help with this. This lets you implement the feature with its boundaries clearly defined--e.g., APIs to adjacent bits of code, expectations about data ...


6

There are two differences between releasing on your own or releasing through Apples App Store: It takes 1-3 weeks to get approved for updates. Often one week, sometimes two, occasionally three. You run the risk of having your update rejected for one reason or another, thus having to redo the release again. Approving rejections is quick (1-5 days) So all ...


6

The short answer is: Do what works for your team. In a perfect continuous deployment scenario you might have this as a workflow: each commit (in a centralized system) or push/pull to a particular branch (in a decentralized system) would trigger the code to be built. If the build succeeds, that should trigger unit tests. If that succeeds, that should ...


6

Imagine your code not as a monolithic system, but rather as a series of packages. Some packages depend on others. Some, such as jQuery, are external to your company; others are developed by your company and made public; others, developed by your company, are eventually made private. For instance, if you develop a web application in Python, you may have a ...


6

See it this way: what you actually did is, you automated the steps of your deployment process in a test-driven manner, just like you can implement any other program or component in such a manner. Since you did this in a "bottom up" way, as a "side effect" you can run the building blocks of the deployment not only for real deployment, but also for the purpose ...


6

Continuous integration (CI) is the practice of frequently integrating changes with the main codebase. In order to do CI, you probably want a CI server running automated tests on your codebase with each commit, verifying successful integration. Developers pushing to the codebase should keep their commits small, and pull/push changes frequently. Continuous ...


6

Yes. The 'Continuous' refers to the automation of the processes rather than zero downtime. Having said that. I would assume that: If there is significant downtime they wont want to continuously deploy. (it would cause lots of outages) There is still a manual step somewhere (a fully automated process is usually fast You can imagine a working CD setup with ...


5

So, for people following the first principle, at what point do you switch from debug to release builds? We switch early, when the source code got a version number and got pushed into the Debian build queue. We are in the lucky situation of doing scientific software with well-specified inputs and outputs and little system interaction, though, so the cost of ...


5

Frankly, I think you should look at them all. Scrum because it heavily emphasizes iterative and incremental development. XP because it gives a lot of advice on the technical side of development. Kanban because it emphasizes WIP limits and flow. That's how I've come to know them anyway; I've noticed they've all influenced each other heavily over the years. ...


5

There are some things which a CI environment can't effectively check. Or things which are cost prohibitive to implement in a CI build process. For example, I work with embedded systems which run on all manner of physical machines. It is incredibly difficult and frankly impossible to perfectly model the entire physical machine for all possibilities virtually....


5

Teamcity will tell you all of the commits that triggered the build. Get a list of names of the people making those commits, and assign the task to all of them.


Only top voted, non community-wiki answers of a minimum length are eligible