Hot answers tagged

66

The problem I see is that the knowledge of setting up and configuring the virtual machine is not in-house, and if configuration is non-trivial then you'll be relying on the other company when the software needs to be configured for different versions of the OS/libraries/hardware/whatever. Accepting the VM is fine to get up and running faster, but I'd insist ...


36

I don't see a massive draw-back with it, but I would say that accepting a VM with the source code on it should entail the same paranoia as accepting a shipment of a machine with the software and dev environment installed, so please make sure there's nothing bad installed on the VM before you spin it up in an environment that has access to your internal ...


21

The classic assert is a tool from the old standard C library, not from C++. It is still available in C++, at least for reasons of backwards compatibility. I have no precise timeline of the C standard libs at hand, but I am pretty sure assert was available shortly after the time when K&R C came into live (around 1978). In classic C, for writing robust ...


20

There's absolutely no "Agile" problem with having a fixed release date if you're prepared to move one of the other two edges of the "iron triangle": the requirements for what needs to be in that release, or the resources you have available. You can't fix all three - and in practice, the "resources" side of the triangle is very often either not very flexible ...


18

I would be worried that there is something configured in the machine that is undocumented, difficult to reproduce, or not acceptable in your standard configuration. Ymmv, but I don't really consider the development done until the project can be demonstrated to build off the standard dev machines and deployed on the commodity servers/clients.


16

If you find yourself wishing asserts were enabled in a release you've asked asserts to do the wrong job. The point of asserts is that they aren't enabled in a release. This allows for testing of invariants during development with code that would otherwise have to be scaffolding code. Code that has to be removed before release. If you have something that ...


13

While what you have done is sure to be a good thing, the project manager has to worry about a number of things: testing - what if you break something. Either something in the home page, or some other unintended consequence? The system needs to be retested. Depending on how far your company goes, this could be a large cost. Scheduling user downtime. May be ...


13

It's a software project, therefore it's overrunning. That's a slightly flippant answer, but this is a very common problem. You say there are "requirement changes constantly incoming": that's why you're overrunning. You absolutely have to have a requirements freeze or you will never ship. Only with the requirements frozen can you issue a release date. Your ...


12

When we make a release, that release contains not only the actual release files but also contains all the meta and testing stuff. This happens because GitHub's way of creating releases is to simply ZIP up a snapshot of a branch. That's not entirely correct, as far as I can tell. In GitHub, a release is a tag pointing to a specific commit - and while GitHub ...


11

What you experience is called feature creep The Dilbert site has a nice collection about this topic. Now, my suggestion at the beginning was to: 1: Set priorities for all the features. I would have proposed the same. This didn't work out well, since about 70% of the features got priority 1, all the others got priority 2. And the verdict was: ...


11

After you've completed a triggered build you'll have a new env variable set to the build number of that triggered build called TRIGGERED_BUILD_NUMBER_<job name>. You can use that to specifically copy back the artifacts: Windows build (called "WindowsBuild"), calls the Linux build (called "LinuxBuild") using the Parameterized Trigger plugin. You've ...


11

I think this is probably best described by stating the bad practices it would seem to be trying to avoid. I can remember the old days when these were common practice. But with modern 'dev ops' tools being so easy to use these days I doubt they are seen anymore. Live code fixes. (Run and Build stages are joined) A bug is reported, I fix it on my dev machine,...


10

In a few of my projects, I've had to fight hard to get software delivered this way. It's an excellent format. Make sure you: Get the source code of each release you get from the contractor, and merge it into your own source control system Get documentation on the VM's environment setup, and can reproduce it in-house. Add the documentation to your source ...


10

I don't think the terms release" and "deployment mean exactly the same, thing I'm not sure they should be used interchangeably like that. From a web development perspective: Deployment refers to getting your program to a running state on a server. It doesn't need to be the production server. You can deploy an application/module to a testing server that is ...


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

In your case, the particular software you are using is licensed under "GPLv2 or any later version," which can be included in GPLv3-licensed code. If the code you wanted to use were using GPLv2 only, then it would not be legally possible to include that code in your GPLv3-licensed distribution. We can consult the inter-GPL-compatibility table from the FSF's ...


9

You'll want to read up on the term "technical debt". If time & resources permit, it is much better to do any code clean up immediately while the problem is fresh in your mind. Leaving clean up as a to-do item for others can turn into a very bad habit. These to-do items are rarely addressed, and after many years can lead to such a horrific mess that ...


7

You should concern yourself with data rather than subjectivity. Thus you should be monitoring/measuring/profiling to determine improvements. That monitoring needs to be in both production and test (and dev) environments. Ideally, you shouldn't be optimizing anything until after you see the results of performance. Otherwise you risk a "premature optimization"...


7

Any professional organisation would have not just build machines but test environments for all those platforms they support. And that's why most professional organisations won't support such a plethora of platforms, it's just too expensive for the small return that each of them yields except the few big ones like for example Windows, Mac, and RedHat based ...


7

There are pre-release phases for software products: alpha, beta, and release candidate. It depends on how mature your product is. An alpha release would tend to indicate that the application is still relatively unstable and perhaps buggy. This would be anything up to a feature-complete release. As you move toward feature-complete, you may want to consider ...


7

You only get one chance to make a first impression. If you release an obviously unfinished buggy app, the first people to look at it will drown you in negative reviews. Once you have a lot of negative reviews on an app, no one will look at it - even if you claim to have fixed the bugs and finished the app. Leave out as many features as you can (i.e., if ...


6

That's really the sort of thing that should have been worked out in the original contract. They may already be going above and beyond. I wouldn't expect to get configuration instructions without paying extra, because it requires more work on their part. I've been in a similar situation as yours before. Our development environment is Windows/Cygwin and we ...


6

You are misinterpreting the word production. It does not refer to the software itself being produced, it means it is being used to produce whatever the company using it produces.


5

A release can be comprised of any set of features you wish. You (and your business needs, marketing, ease-of-upgrade for your users, etc) determine what should go into a particular release. If you want to release a single version that has two new features, go for it. If the added functionality is backwards-compatible, you would increment the minor version, ...


5

You are confusing your source code with your deliverables. All your source code, all your documentation, all your test code, should all be in your git repository. And then you should have a build script that extracts all the deliverables into one directory (with subdirectories obviously), and that gets shipped to the customer. Let's say for a new feature ...


4

Well first and foremost, it has to pass all your regular Q/A steps AND show a real performance improvement. Now you're faced with a business problem: the client has what they paid for. They've accepted it, and are using it in production. They think the project is finished. It is possible that they don't want to risk 'rocking the boat' for an update that ...


4

What question(s) should you be asking the users? Here is the next version of our program. Please report any unexpected behavior. Unless your users are using stopwatches, or your program has some very long-running processes, users are unlikely to be able to provide anything but subjective feedback. And for optimization I'd be more worried about behavior ...


4

As FrustratedWithFormsDesigner said, you need to know how to set up the machine for yourself. However I would like to add that you could potentially ask them to provide a script that configures the machine for you, rather than an entire VM. If the script is written well enough, you'll have exact up-to-date documentation of how to set up the machine (by ...


4

The important thing here is to have a consistent workflow which can be easily followed by both newbies and veterans in your organizations. Decide on a process which meets your requirements and ensure that the workflow makes sense for both trivial and more complex changes. That said, there are a few standard workflows out there. Here's a few of them: GitHub ...


4

I'd suggest continuous integration of any useful incremental work from any developer in a single integration branch, with automated and manual QA done as often as possible on the integration branch. Everybody is on the same page, no room for "wandering off" or wasting effort and resources polishing changes (in individual dev environments) which may be ...


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