Popular posts

Ah, just continuous integration and deployment in the easiest sense. :) I should check in code and boom, i should see it in production.

That didn't give me much insight 😛 do you have a link?

@emilmoe, Well, we build features and solve bugs all day, right? We first test it on our local machine and then push it to a version control system like github. The next step is getting your changes deployed on a staging (or even production server if you're a badass) to make sure you are changes didn't break anything and is working as expected. That's when you go to your DevOps guy or the backend guy and ask him to ssh onto the machines where your application runs, pull the latest code and restart the application, so that you could see it in action. Crudely speaking, the DevOps guy does the CI/CD in this scenario. CI/CD tools are a bunch of SAAS products that eliminate the need for a DevOps guy. So, ideally when you use one, you will hook up your repository to your SAAS product. Each time you check in code, the SAAS product will run your tests and deploy your code to wherever you need it deployed. Does that help at all? :)

Yeah it helps, it checks the tests are valid and do actions based on those results, or am I completely wrong?

I think the problem is that I am mainly the only dev on the team, so it's so easy to be a little lazy on the test parts since I have 100% overview. I know it's wrong, and that's why I try to force myself on a more structured behaviour.

You're spot on :) However, when you want to scale, you should automate and focus only on writing code and not spend your time figuring out how to deploy.