What is the process to get code into prod?
For further actions, you may consider blocking this person and/or reporting abuse
What is the process to get code into prod?
For further actions, you may consider blocking this person and/or reporting abuse
Archie -
Luxand.cloud -
BekahHW -
Gokay Buruc -
Oldest comments (72)
The coolest and most frustrating thing about DevOps is there's a hundred different ways to do something. I say this in hope I won't be judged too harshly for how we do deployments.
I should first mention that we're not a company in the web app space. The company I love working for primarily creates cross-platform C++ applications that run on Linux/Windows appliances. Also, as a DevOps Engineer, my customers aren't always actual customers. More often than not, they're developers. When we deploy, we remotely update the Linux or Windows platform, then uninstall anything existing software, reboot, then install the most up to date software, license it, and verify the installation was successful.
We accomplish this primarily through Ansible playbooks that deal with the actual deployment, and use Jenkins jobs as the self-service mechanism for our developer customers. When devs want to upgrade their systems to test or do whatever, they can go to Jenkins, enter their IP and select the version to install and click 'Build'. The rest of the process is seamless to the customer, with the exception of the 'DevOps is deploying' screen we run during the deployment to let the remote user know the system is doing something.
I know we could look into Ansible Tower or FOSS alternatives, but people got used to Jenkins so I try to let that be the common interface for self-service tasks performed by our developer customers that need an automated capability.
AWX should meet your needs , it s basically Tower for free and integrates with your existing ansible roles
github.com/ansible/awx
Honestly - it's just FTP & manual database pushes π€·ββοΈ
It's not sophisticated or fancy, but it works.
No shame in not using βfancyβ CI tools. Whatever does the job.
Obviously you don't have to be ashamed for not using "fancy" CI tools, but when you do, you'll see why people are using it.
I learned on last 10 years that technologies that meet a need stay, and technologies that don't, disappear or remain in legacy projects.
Git isn't something new (as you should know). CI scripts aren't new too, it only simplified the two-step task - where you were using git, svn, mercurial or wharever with a Rundeck or similar automation that needed to be fired manually - into a single step one where devs only need to push to master (if permissions) and it all rolls smooth into production and able to roll-back easily if needed.
If you are not using a version control service, then yes, you need to be ashamed.
I agree with Ben, "Whatever does the job". I worked on a company that had this approach too with huge legacy products. I wrote an script to automate deployments like that with ssh, maybe could be useful for you: github.com/felippe-regazio/sh-simp...
Thank you for your answer, it's important to keep in mind that even though we read all day long about fancy new techniques and tools, most of us are working on legacy codebases and deploying manually.
That said, Continuous Deployment is not just a fad. I recently changed jobs and moved from gitlab CI/CD (which is really nice) to a mix of "git pull" on the server, SFTP, rsync, and running the migrations manually... And it's a huge pain and a huge waste of time (not to mention that if something goes wrong we don't have an easy way to rollback to the previous version).
I haven't yet setup CI/CD pipelines because we use on premise Bitbucket and it doesn't seem to offer CI/CD (so it means we'll need to install Jenkins or something and I'll have to learn that), but it's pretty high on my todo list.
It does, itβs called pipelines I think. Itβs pretty descent.
As far as I can tell pipelined is only available on bitbucket cloud, and not the self hosted version (bitbucket server) ? I'd love to be wrong though.
Ah ok, I don't know more about that.
I used to be on BitBucket too, but i definitely changed to GitLab and I find no reason to use something different, i recommend you to take a try. I don't use self-hosted but i guess you will have same options.
We zero-downtime deploy our applications (mostly PHP - Laravel or WordPress - but not only) with deployer.org/.
Very easy, fast and reliable.
This is awesome! had never heard of it. Will give it a shot with Craft CMS (yii2) base platform.
Gitlab CI/CD at my βFinancialβ Support Org.
Github Actions at BarelyHuman
AWS CodePipeline + AWS CodeDeploy + AWS CodeBuild
What stack? I have run into issues using NextJS with this deployment approach. TIA
Ruby on Rails, though the process is identical because NextJS is just a nodejs app.
I had a course I made on Udemy last year for creating a pipeline with Rails but you could just ski the Rails part. I've been meaning to release that video course for free.
I would love to get to this point with my job.
Same here, only our stack is HTML/JS/CSS + Python/Django + MongoDB/MariaDB. Every code merged into develop branch on Github Repo is immediately deployed to our dev/staging environment also on AWS, same process on master -> production counterparts.
Jenkins with GitFlow for larger, high-risk products that require more gates to be crossed, and plain ol' jenkins plus github hooks to automatically build and deploy for smaller products and products with less risk.
Whatever works for you, the tool chain should match the need!
We use GoCD to handle the deployment, from Bitbucket, our repository, to our Docker clusters on AWS.
Just the netlify cli for static sites and heroku cli for dynamic sites.
At the day job we have several projects that are deployed independently using BuildKite.
For a freelance client I use CodeShip to handle the deployment of a Firebase hosted site, Firebase Functions and Firebase Database migrations - triggered by a push to the repo. Each branch in the repo deploys separate site/functions/db.
For most small personal projects I use react-static and Netlify; so it's simply a push to the repo.
AWS Amplify for the frontend app and our serverless backend.
It depends on which environment you are trying to deploy to. At my company, we have multiple environments of the same application. One for Dev, QA, and Production.
For the sake of brevity, lets take a deployment from QA to Production. Note:
Local Machine -> Dev (Do it as many time as your heart's wish π)
Dev-> QA (OK with some restrictions) ,
QA-> Production (OK with a lot more restrictions),
Dev->Production ( A BIG NO NO, could get me fired!).
This process is very cumbersome at time and deployments can often span days. However, I have heard talks of going fully automated deployments π, but they are still trying set up the bolts and nuts for the whole operation.
So, you have an operations team which is named devops?
I bet everyone at the company is annoyed at how "devops" has made things more complicated for little benefit.
It seems one of the biggest challenges with these new development processes is that it requires a true collaboration, something not heavily prioritized and actively avoiding. It is so much easier to create definitions for interface handoff. We do it in good software architecture all the time.
As a consultant, weβve implemented and worked with a lot of different CI/CD stacks. But most of them are a variant of..
Bunch of auxiliary tasks and checks on top of that basic setup.
Sad to say!
People here just edit the files directly from WinSCP π€·ββοΈ, But I'm insisting all to implement CI/CD via GitHub actions and use SSH/SFTP based deployment to Production / Canary / Staging.
We use jenkins. Everytime someone create a branch and push something jenkins run all the tests and build that branch independently. and if everything is okay. We create a artifact as gzip and upload it to aws S3.
Then everytime someone want to check the changes on that branch, we have a separate page in jenkins that we can say which environment you need to deploy specific branch. You can select a environment by a dropdown and need to type banch name. Then it will download the changes from S3 and extract it and copy changes with rsync. Then it will restart the process. Within 5-10 seconds. You are ready! We only allow prod to deploy master branch! Within this approch we can test any branch at any test env. So you don't want to have staging, dev etc branches other than the master!
There's more than one application which we serve at my company.
The first application uses a dated deployment, which goes like this:
There's a couple of issues with this kind of deployment. For some customers we incur business loss because they've got people around the globe working at different hours.
The second application uses a rolling deployment, which goes like this:
There are some special considerations with regards to how migrations need to be written since the old application will still be running. For example removing a column needs to be split into two releases instead of one.
To answer your second question, our SDLC (software development life-cycle) looks for the most part like this: