Hacker News Reader

Comment by Zeu5 | Hacker News Reader

I thought having a proper continuous deployment helps with development?

I want to shorten my learning curve and honestly I have my hands full.

Other people created startups by hiring freelancers to do their coding, so your argument about being exposed to the risks of not being able to fix the very thing that the hires created also applies to them.

I am quite sure they were not stopped by that.

I do acknowledge that risk you are talking about hence I am also requesting for documentation and a proper handover.

Basically, I would like someone to a) implement the setup for me once b) show it to me how it is done c) undo everything and let me do it once.

If not possible to do all a, b, c), i dont mind hiring someone to at least do a) and b).

Thank you for your reply.

View on HN

Development and deployment are two different things. Just as development and system administration are two different things. Deployment is actually more in the realm of administration than development. So, I'm not sure you can say deployment helps with development, though it's good for a developer to know about the administration side also.

To say "Other people created startups by hiring freelancers to do their coding" is too much of a blanket statement. This is something that has to be carefully considered on a case by case basis. Outsourcing works in some cases and it's a disaster in other cases.

You mention that you need someone to hand over the documentation, but that's not the sorts of problems I'm referring to. What happens if the server hits a hardware failure and you have to work outside the documentation to recover? I run into crazy stuff with Administration all the time, it's never so tidy that I can work any sort of documentation people could hand to me. If you don't have a basic working understanding of what you are working with and nobody on staff who can do the same, then you are at the mercy of the same issues you are running into now.

I guess what I'm getting at is that you need a process which you can run yourself even when things go very wrong. If you start relying on processes that you can't handle in house (you) then those processes become liabilities rather than assets.

>I guess what I'm getting at is that you need a process which you can run yourself even when things go very wrong.

Okay. So now the question is how do I go about getting that?

Finish the app first. Once you get to a point where you are at least closer, maybe almost to beta then you will see how deployment issues are a problem. I would then start working on your deployment process. At that point, it's all reading and Googling. ;)

I understand what you mean. You are telling me not to put the cart before the horse.

I am thinking of deployment in the sense that, when i do a push of the repo code to the staging, the unit tests are executed and if all tests are passed, the code is then deployed on the staging proper.

Else it will be rolled back.

I do not have a) staging b) unit tests c) a hook to run the unit tests when code is deployed to staging

I guess the above are important to development yes? Helps to discover bugs easier right?

A few thoughts on this...

Almost anything that can be automated can be done manually (or with minimal scripted automation) first, often with pretty good results. It's generally a good idea to start simple, and don't add complexity and extra work (like configuring/managing automation!) until you are addressing actual needs that you have... at that point, you can measure the pain to decide how much effort to put into the fix.

The first step to automated deployment is manual deployment using a checklist. Before automated unit tests, you have to write unit tests, and be able to execute them manually. Before automated rollback, you have manual rollback. Etc..

Are your developers able to run the entire project locally? If so, you are starting off with frequent local deployments, and if you encourage them to implement features in small steps and sync with version control after each step (i.e., at least once a day) then you also have achieved frequent integration builds - each developer is doing them independently. Next, throw in a script that executes all of your unit tests, and run that yourself daily (don't automate it into every build... that'll swiftly make them too slow and devs will start avoiding builds...), then email everyone when something is failing.

In other words, with a simple cultural standard -- don't hide in a hole and code for a week, and write unit tests! -- you have already solved (for a small team) most of what continuous deployment addresses. And you haven't put any time whatsoever (or spent money/time hiring someone) into setting up some non-trivial automation yet.

The other advantage is that by the time you are seriously ready to automate your build, it may be quite different from what you have now -- it depends on where your project goes, if you make a large pivot, mix in new technologies, and so on.

This solution might work for quite a long time; are there good reasons to implement continuous deployment instead, from the start?

Other than the cool factor, I don't think so.

Right, I agree with all this.

The unit tests will help you with bugs by ensuring your program is doing what it should be doing.

You shouldn't be worrying about automating your testing before you have even started writing unit tests.

Don't try to automate things you don't yet know how to do. Figure out how to run it manually first.

Staging isn't so important at this point. Staging is generally most useful when you are showing a working version of what you are building to a client (or anyone who might need to see it) while you are still in development. In this case, your code is always changing and you are regularly breaking things. If someone needs to look at what you are doing then you need a stable snapshot setup for them. This is especially important when you have multiple developers because you don't know what the other guy is doing. The end game is that your code has gone live and the "client" is your actual customers. This is where being able to push your code to a staging server is critical. You need to be able to "user test" it before going live.

>Staging is generally most useful when you are showing a working version of what you are building to a client (or anyone who might need to see it) while you are still in development.

Yes I do have 4 people to demo to.

>This is especially important when you have multiple developers because you don't know what the other guy is doing.

Yes I have 2 developers working independently. I hired them to increase the speed of development. Plus myself, that is 3 people working on different parts.

so my question is how do i get someone to help me? or point me to the right resources?

I am getting the feeling that i am being perceived as someone enamored with a buzzword and ignoring basics.

I am also getting the feeling that the term continuous deployment is perceived as a gigantic ball of multiple scripts and processes for deployment, only suited for projects of a certain size.

I am going to state the following unspoken assumptions of mine. My bad that I unknowingly assumed that other readers believe in the same assumptions.

Hope this will help the discussion.

From a web application perspective, my assumptions are

a) continuous deployment/integration means able to (as much as possible) automate the process of deployment of the code on a server preferably one where the configuration is identical to the production server. regardless how much the code is completed.

b) continuous deployment/integration means able to (as much as possible) automate the process of testing the deployed code against unit tests or functional tests therefore allowing developers to add new features or re-factor existing code without fear of integration risks.

Again, I would like to seek help to automate (as much as possible) the process of deployment.

I already have Capistrano working but to a production environment.

I am not looking to hire from HN readers, though I do not rule that out. at the very least point me to good places to look for such people.

Like a stranger in another country, I need directions. Either take me where I want to go, or tell me where I can ask for better directions.

I hope that analogy works to express what I am asking for.

Thank you very much to all feedback so far.

Initially, of course there is no problem with local deployments aka localhost.

Now there IS.

Because I need to have https, some pages have now broken.

Clearly the developers I recently hired and myself CANNOT test against https on local deployments.

>The other advantage is that by the time you are seriously ready to automate your build, it may be quite different from what you have now -- it depends on where your project goes, if you make a large pivot, mix in new technologies, and so on.

Yes I agree with you. But what I am asking is that currently, the code has grown to a size where i need to have the proper amount of automated processes for deployment and testing and I do NOT have the chops to do it myself.

So I would like to have some directions as to how to go about it myself? or hire someone to aid me?

Set up your builds to use a variable to control whether secure links are http or https. For development builds, the variable can be set to "http"; for production or staging server builds, "https".

You can also just use https on development machines as well, but use self-signed certs. I avoid this approach, though, because Selenium testing in most browsers is broken by the browser popup warning. (If you aren't using Selenium, though, this is a simple solution to your breaking pages).

As far as hiring someone -- I think posting to HN is a good start. Unfortunately, your best shot is someone who has some spare time to spare for a side project (because it's a fairly sure thing that the kind of person likely to have any real experience in continuous deployment has a real job already).

Alternatively, you can hire someone to help figure it out for you. That was actually one of my "trial" tasks at my current main job -- I figured out Selenium testing for them, designed a bunch of tests (this was also a great way to learn the webapp) and wrote a standalone GUI so the anyone (including the CEO) can tweak, run & step through all existing tests.

I was attracted to the job because it's completely remote (required for me, as I'm not allowed to be employed in the country where I live), and I had lots of experience in the technologies they're using. They didn't hire me for experience in automated testing (I didn't have any); they hired me because they thought I'd be able to figure it out quickly.

HTH.

That sounds interesting.

Yes I'd like to get someone to help me quickly figure out Selenium testing, and build automation which I think I seriously cannot spare the time for.

Even if I cannot get someone to help me figure out everything about continuous deployment at this point, figuring out some of it is good enough.

(I consider Selenium testing, etc as part of continuous deployment)

That person can work anywhere. As stated in my very first post, I hired an expert from the UK to help me with my Amazon Web Services setup for multiple SSL certs, so location is a non issue.

Who can you recommend to me? If the person is wary of my ability to pay up, I can set up a job in elance that the person can view and the transaction can take place over escrow funding. In fact I already have.

Do drop me a line at kimcity -at- gmail -DOT- com to hook me up with someone like that.

Appreciate the help.

Thank you.

Reply on news.ycombinator.com