5 ms·

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

by Zeu5 16y ago

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

gexla 16y ago
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. ;)
- Zeu5 16y ago
  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?
  - jtheory 16y ago
    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.
    - gexla 16y ago
      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.
      - Zeu5 16y ago
        >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.

by Zeu5 16y ago

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

gexla 16y ago

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

Zeu5 16y ago
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?
- jtheory 16y ago
  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.
  - gexla 16y ago
    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.
    - Zeu5 16y ago
      >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.