96

Using a scripting language in place of a config file looks great at first glance: you have the full power of that language available and can simply eval() or import it. In practice, there are a few gotchas: it is a programming language, which needs to be learnt. To edit the config, you need to know this language sufficiently well. Configuration files ...


81

Code that works for you and is easy to maintain is by definition "good". You should never change things just for the sake of obeying someone's idea of "good practice" if that person cannot point out what the problem with your code is. In this case, the most obvious problem is that resources are hard-coded into your application - even if they're selected ...


51

+1 to everything in amon's answer. I'd like to add this: You'll regret using Python code as your configuration language the first time you want to import the same configuration from within code written in a different language. For example if code that's part of your project and it written in C++ or Ruby or something else needs to pull in the configuration, ...


22

The other answers are already very good, I'll just bring my experience of real-world usage in a few projects. Pros They are mostly already spelled out: if you are in a Python program, parsing is a breeze (eval); it works automatically even for more complex data types (in our program, we have geometric points and transformations, which are dumped/loaded ...


16

Possibly there is no one good answer to this. It seems that you need to store this data somewhere safe, as it will be needed for disaster recovery purposes one day. This applies equally to properties files and scripts that set environment variables. With the source code (in SVN/GIT etc) is a really bad idea, as this data will contain production database ...


14

You are absolutely right in thinking this is a bad practice. I've seen this in production code, and it always comes back to bite you. What happens when you want to add another environment? Or change your development server? Or you need to fail over to a different location? You can't because your configuration is directly tied to code. Configuration should ...


14

The simplest solution, IMO, is to have a decent number of automated tests for each product. When you update a library, you run the test suite for each product. If the tests fail, then you will know which products need to be updated.


13

While not being explicit about it, SemVer applies to released packages. Therefore, if you, as release manager, build a package containing all 3 commits then you only have to increment the version once. If you choose to release them in separate packages then you have to increase the version each time you release.


13

Git is not suitable for managing different variants of your code. Git is not a deployment mechanism. Git is just a source code management system. One thing that gets lost when using git push as a glorified FTP command is that source code is source code, and not necessarily the same thing you deploy. That even holds for interpreted systems where the ...


13

The term configuration management belongs to the general engineering vocabulary. Its purpose is to keep record of the characteristics of all the parts/components of a complex system (e.g a car, a missile, an electronic device), and of course the change of these characteristics when a component is replaced with a similar component. A configuration describes ...


11

I am not a Scrum expert, but AFAIK "collective code ownership" is meant to be per team and per product (and I think your question is not specific to Scrum, it could be applied to any "shared code" development process). If you have two teams A, B, two products A, B and a shared component C, there are different possible scenarios. Maybe the shared component ...


10

All the tools that you have mentioned (Jenkins, ant, git )help to actually build and test your artifact. In java world usually this can be war, ear or just zip with the application inside. Sometimes for complicated applications it can be more than one artifact. For other programming platforms it may vary, DLLs, binaries for multiple different platforms and ...


9

Configuration (information about the environment required to do work) Create a configuration class (to be picky: an interface + an implementation) which purpose is to provide the information about the environment. This makes the configuration in no way different from other objects required for your object to do work (point 1). Parameters (Data that work ...


9

Configuration Management (CM) folks don't think like programmers. They think more like auditors. The reason they want a list of the files is because they want to verify that they got them all. Yes, this seems silly to a programmer, but it seems natural to someone who doesn't trust a single source of information. Ideally, your list of files would not ...


9

There's nothing "agile" about a 3-year merge. Your team is going to have to put "agile" aside for a while, probably considerably more than a single sprint. You're going to want to freeze current codebase before you merge and extensively test, so you'll know that the starting code is fully functional. Then you're going to have to do the full merge, ...


9

In examining problems and possible solutions, it helps me to use a method popularized by Jeff Atwood: If God were to create a way to store sensitive configuration information, how would he do it? Well, he would know who needs configuration information and only give it to those people, and the information would never be able to be accessed by anyone else. ...


9

Use a tiered approach (not all tiers are necessary): Load base properties from classpath. Override with properties from /opt/app/conf, IFF such a file exists. Override with properties from $HOME/app/conf, IFF such a file exists. Override with properties specified using environment variables. You could also use variations on this approach, such as using an ...


8

In the situation you describe, you are not getting any benefit from having multiple repositories, but you do have a cost: you can't roll back to an older version of a repository, and have any confidence that your system will continue to work. This is because your code is tightly coupled across repositories. As confidence in the ability to roll back is one of ...


8

In a large organization that does best practice software development the development infrastructure is the domain of IT - as it should be. These servers are usually locked down just like any other server, and developers do not have root access to these machines. (Would you give the Office Admin root access to the corporate email server) IT will have an SLA ...


8

I agree with MetaFight, this is a tough one. Just to throw out a contrarian view point, do you really have to merge the code? You have two large blocks of code that share a common ancestor. They split off from each other at least 3 years ago. The blocks have been maintained by two independent groups who apparently don't talk to each other. What value ...


8

The main question is: do you want your configuration file to be in some Turing complete language (like Python is)? If you do want that, you might also consider embedding some other (Turing complete) scripting language like Guile or Lua (because there could be perceived as "simpler" to use, or to embed, than Python is; read the chapter on Extending & ...


7

This is a tough one. Having to merge two branches of code you're unfamiliar with is tough to begin with. Add 3 years of divergent development and you've made it something I would quit my job over ;) But let's be constructive. There is no easy solution for merge conflicts. You'll have to resolve these manually. And, unfortunately, with every merge ...


7

The introduction to the R Packages book explains the benefits pretty well: In R, the fundamental unit of shareable code is the package. A package bundles together code, data, documentation, and tests, and is easy to share with others. As of January 2015, there were over 6,000 packages available on the Comprehensive R Archive Network, or CRAN, the public ...


6

There is no concept of "clear architectural vision" in Scrum or agile! I have long been an architect, and it's clear to me that in order to have have an architectural vision one needs to have a clear view of future requirements. Since in most cases the requirements aren't clear at all, it doesn't make sense to have a fixed vision. What is necessary is to ...


6

(in my experience) Major decisions (especially involving product owners) belong in design documents. Trivial technical decisions (why is is field empty?) belongs in a comment right next to the field. In between sort of decisions are odd. I tend to think that undocumented communal knowledge is best, since documentation of a decision is useless if nobody ...


6

Sounds to me like it could be a big mistake to to treat this as just a big example of a merge, something that is going to involve an unusually long set of sessions sitting in front of a merge tool and pressing 'accept/reject changes'. Instead, I would: Spend an appropriate amount of time, perhaps a week, reading both sets of code. Decide which one has the ...


6

Many people criticize storing configuration in regular files together with your source code but in my experience, this is actually a pretty good solution: Simple to implement in any language. In many, you get support for complex configuration files out of the box. E.g. in the case of Java with Spring Boot, you get YAML support which can express any tree-...


6

The idea of HEAD is that every time a developer starts a task, they start with HEAD, and when they are finished they merge back into HEAD. That way you always know where to find the latest version of the code. You are doing something different. It sounds like each programmer begins by selecting a somewhat arbitrary tag from the existing tags and starts ...


6

If you are going to have the same file in four repos, and allow it to be changed in any of the four places, you will sooner or later run into the problems of collisions, how to work with branches, how to handle commit messages, and so on, for a multi-repo case. Of course, you can try implement some homebrewn solution using SVN hooks, batch scripts and diff/...


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