136

Normally you wouldn't just have a dedicated build machine, but also run a build server on that dedicated machine. A dedicated build machine merely offers the advantage of never blocking the work of a developer and deploying from a centralized machine. A build server offers much more. A build sever allows for CI (continuous integration), meaning that it ...


107

In addition to Traubenfuchs' answer, you have hinted at another reason for a build machine in your question. Just because the software builds on your machine, it doesn't mean that it will build on anyone else's. You may be relying on some random files that just happen to be on your machine (and may not even be under version control). You may be relying on ...


104

Which is best practice? to manually deploy one project artifact each deployment or keep doing the file by file deployment? Neither. Best Practice is to automate your deployment, completely and exclusively. That means nobody gets to put anything onto a server manually. "To summarize the summary of the summary: People are a Problem." (Douglas Adams) ...


87

Not at all. Imagine you're running the version 1.8.0 of Java on both your development machine and the server. By the way, you're working simultaneously on two projects, both using Java. One day, a bug is found in JVM, and the servers which run the first project you're working on are migrated to 1.8.1. By the way, the servers running the second project aren'...


53

The main reason for having a dedicated build machine is to get consistent builds regardless of who is doing the build. Developer workstations are rarely (read: never) identical. It's hard to know that each build is using the same exact versions of dependencies and compilers etc. One of the worst problems with dev workstation builds is that developers can ...


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 ...


35

You rarely just deploy a "Java App". Your java application has a lot of different support programs around it. We use Apache HTTPD, Apache Tomcat, ActiveMQ for messaging, an FTP Deamon, MySQL and a handful of custom services to integrate with programs that don't work directly with Java. This doesn't even go into the development software that goes along ...


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 ...


22

In layman's words: Not all users use all of a company's apps Different users have different needs Why force an user to buy a full package when he/she needs only a part ? (Ok, Google apps are free, but other software maker's aren't.) Having those apps separate makes it possible to be updated separately and, most importantly, sold separately. The fact that ...


20

An installer always makes sense, if deployment requires anything more complicated than copying the relevant file(s) to some folder and running the EXE. If there are additional steps that need to be taken to set the product up properly, there's two ways to go about it. You can write out a list for someone to follow. Humans being humans, someone's bound to ...


19

The other answers quite correctly noted that you should automate the build, which means it isn't necessary to walk to another office. However, let me propose a certain number of steps you could take to improve your build process: Firstly, set up remote access to the build server! If you build manually by typing the command "make", this means you don't have ...


17

I really don't think its a huge complexity for the end user to have to select either a 32bit or 64bit option when downloading. But if you can use the user-agent strings to make a suggestion all the better. Another option is to have your installer detect and install the correct binary for the user's platform. That makes for a larger download, but then the ...


17

No. Source control should only contain source. If it's generated from source, it doesn't belong there - and should be generated by your build process. The fundamental reason you don't want to source control intermediate build artifacts is that if you do, it gets really hard to trust wether what you're running comes from the source you just modified, or ...


16

... instead of getting an actual machine in our office to use, we're having to share a single machine with several other groups ... You say that like it's a bad thing. You now have a common build server that all of your builds - yours and the other teams' - are built through. Consistency of build? Check. ... the hassle of having to leave my office ...


16

Why not? Any of the things you describe would be a problem whether you use continuous deployment or not. The problem, it seems, is that you are worried the juniors will make a catastrophic mistake. And that that mistake will be rushed into production before anyone can catch it. That's why you do code reviews and do testing. Before anything gets merged ...


15

This is a very pragmatic approach to database-backed software upgrades. It was described by Martin Fowler and Pramod Sadalage in 2003 and subsequently written up in Refactoring Databases : Evolutionary Database Design. I can see what you mean when you say that it seems sloppy, but when done intentionally and with forethought, and taking the time to refactor ...


14

"It depends." For normal development tracking, no. For cloud and DevOps deployments, however, it's often convenient, or even required. Most of the time, @ptyx is correct. Indeed, his "no" could be stated somewhat more emphatically. Something like "No. No! OMG NO!" Why not store minified or compressed assets in source control system like Git? They can be ...


14

Manual steps take a lot of effort and are risky: you might forget a necessary file. Maybe not everyone in your team knows which files need to be copied. All of these issues make deployments big, daunting, and rare – completely unnecessarily. Automation addresses these. Even the simplest automation step can have big benefits, because deployments become ...


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

ASP.NET MVC applications are compiled. This means that you can't just upload the changed files, like you do with a PHP website, for example. This also means that when you'll start to update the site, current users will be thrown away (lose their sessions, for example). There is also much more to do than simply update the files: you have to handle: ...


13

A version number is a minimal hindrance to an attacker and a great help to defenders. Frequently, attackers will just try an exploit without bothering to check a version number. I get several windows-based attack attempts per hour in my snort logs, and I haven't owned a windows machine in decades. The exploit working is the only confirmation they need. ...


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 ...


11

Wyatt takes off his programmer hat and puts on his Director of IT hat If this is an internal line of business application then you only need aim at one environment -- said business. I would call the head of IT and ask him how they would like to manage deployment. IT departments have been dealing with this for a while so they might have a strong preference ...


11

I'll share what we've been using, and where we're planning on going, maybe it'll help give you a better idea. We currently use Jenkins and Github together-- once something is merged into master, Github tells Jenkins and it kicks off a build. We use a Nant script on Jenkins to build the project, run unit tests, and if everything looks good, it kicks off ...


11

Realistically, there are none. If you make a hash based on the user's hardware, then when they upgrade a hard drive or CPU or network card, or heaven forbid buy a new computer, the software stops working. Users will get pretty angry about that. If I were a business and ran into software like this, I'd stop buying from that developer. If I were a home user ...


11

The point of the “blue–green” terminology is that there is no permanent hierarchy between these environments. Either environment may currently have the role of the production system, with the other being a staging system. For example: blue is live, green is staging prepare new deployment on green switch over to green: blue is staging, green is live


10

As you can't control when the mobile apps will be updated to a new release, you need to version at least your REST API. If you don't it will be impossible to make backwards-incompatible changes to that interface. Besides the REST API, it is a good idea to version also the other communication interfaces that go over a network interface. That way, you are ...


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

There is a simple reason why MS does not like this model - if any program contains its own version of the .NET framework DLLs, Windows Update would not effectively be able to supply any security updates / bug fixes any more for the .NET framework DLLs. And this is not a hypothetical issue: every few months, a new patch or security update for the framework ...


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