In the real world you really want to come as close to just hitting a button and having everything be automated as you can. If you are installing yourself it's worth the effort because of the time it saves and because you want to make it very hard to make a mistake with live software. If you aren't then it's worth the effort because in almost all cases few people will deal with a difficult installation process.
This can be quite a lot of work but it's conceptually pretty straight forward. You have to write code that verifies that the transitive closure of all dependencies are satisfied and either fix anything missing or have a good error message. If there are installation options that you can't know in advance you have to support setting those via a UI or script or both. You have to play nicely with whatever standard installation mechanism(s) exist in your environment.
Dependencies might not just be files, but might be things like making sure windows registry entries the program relies on are present, configuring a web server for the program, etc.
Basically you have to do programatically everything someone would do by hand, handling all the different possible scenarios.
Automated build is a pretty self explanatory term. A lot of times the build doesn't get quite all the love it needs, and the build process is written in a document with a lot of steps. It's generally worth the effort to have some form of configuration driving a completely automated script. That's an automated build. Usually part of the build is running automated tests to make sure that not only does the build produce a program, but that at least the tested parts of the program actually work.
Continuous integration isn't feasible without an automated build, which is a big reason an automated build is worth doing. It means that the build gets run automatically using some scheme (like "whenever new code has been checked in since I finished the last build I was working on"). Generally a big part of the value of this is that the build runs automated tests, so if code changes break some distant dusty corner of the program you find out automatically and fairly quickly. There may be some value in just knowing it all still compiles though.
Distributing your work and making it easy for others would involve making an installer and following whatever conventions your audience might expect, like putting in an app store, or a source code repository. There are a lot of tools in various environments that, given a name, go find code for you and install it. Your code can participate in that if you follow all the rules needed for those tools to work.
I've been incredibly general because the gory details vary quite a bit in different environments, so a specific answer would depend greatly on exactly what you are doing.