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


103

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


86

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

The best practice is to have an approximation of the production stack on your local developer machine. This typically includes the database, web server and your customized code. Do all of your development there. Never edit code on a production server. When your business stakeholders are ready for the functionality to go live, push your code from your local ...


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

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

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


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


14

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

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

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


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

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

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


10

MySQL is Free Software licensed under the GPL, and it changing owners isn't going to affect that (that's pretty much the entire point of the GPL). Where you need to pay is if you're distributing MySQL as part of a binary that you expect people to install, but don't want to license the entire binary under the GPL. Because of the way copyleft licenses work, ...


10

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


9

Packaging You would probably want to play to the normal expectations for each platform involved. For example, Linux software is usually distributed through package managers, or as a package (RPM file, DEB file), or in the most basic form, an archive like tar, or a compressed tar. In the Linux world, though, since every distribution has very different ...


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