<p>I am in a similar pair of shoes as you - I am currently, slowly, getting into the DevOps topics after having many, many years of conventional development (and close connections to conventional ops) behind me.</p>

<p>You seem to have read a few articles, or heard a few things. That is good. Let me suggest a practical approach how to go on:</p>

<ol>
<li>Take your favourite application (which you or your team wrote yourself); not too large, preferably with a limited amount of services (like Apache, DB etc.) working together with your app.</li>
<li>Install <code>docker</code>, read a bit on the Dockerfile and the whole build process, and just go ahead to create one or more Dockerfiles for that application. You know already how to deploy it manually; now make it run inside a container.

<ul>
<li>Make it easy on yourself. Use a <code>FROM</code>parent container that is a full-blown distribution of your choice. I like <code>debian:jessie</code>, but you can pick whichever you are familiar with.</li>
<li>At the start, do not worry about image sizes. This is just a pet project. Start your Dockerfile with the <code>FROM</code>, then as many <code>apt-get update; apt-get install ...</code> as you need to get your application running. Add stuff with <code>ADD</code> and <code>COPY</code>liberally.</li>
</ul></li>
<li>Learn how to actually run those containers; how <code>EXPOSE</code>works, how  to <code>--link</code>the app together with the DB and the Apache (in case you made a separate container for that - you can skip this obviously if your app is able to serve all stuff including static pages itself). Figure out how to mount/bind <code>volumes</code>, how to debug a container by opening a shell inside it and so on. <code>docker-compose</code> is nice if you have more than one, and pretty simple to get going with.</li>
<li>Now you probably have a working setup. That's great! You have learned the basics, and you immediately feel the great power that comes from containerizing your app. You can deploy it instantly on any server, you can give it to your developer colleagues and go up and running in zero time, and so on. Enjoy that feeling for a while.</li>
<li>Make the image smaller. There are a few obvious things you can do (google...), and a few not so obvious ones (thinking is like googling, just better... :) ). If you need help on that, post more questions here.</li>
<li>Get Jenkins (feel free to do so with docker, again, if you're adventurous) and make a job to build the image from the Dockerfile and run your test suite directly in the container you built. Jenkins can check your repository for updates automatically, you don't need to bother with <code>git</code> hooks at this moment.</li>
<li>You're done! This was the CI part. For CD, after the tests are green in Jenkins, simply tag the build and send it on to your deployment server.</li>
</ol>

<p>This should take you, if you are an experienced developer and have done these things "dry" already, not much longer than a few days. Docker itself is a pretty simple affair, there is not much more to it. One further part that makes sense to add to the puzzle is Ansible, which makes it pretty easy to manage another machine remotely (i.e. for installing packages, deploying stuff, starting services and whatnot).</p>

<p>If you have Docker and Ansible down, just get your CI/CD pipeline to work. Google advanced, but necessary stuff like security and such. After that, you should be experienced enough to decide in which direction to go next (i.e., larger stuff like Openshift/Kubernetes, or just whatever AWS/Azure or whatever have to offer, etc.). There are a myriad of different options out there, and much of the choice seems to be pretty opinion-based. If you get into High Availability, swarms and such, it will also pretty soon get more non-trivial. But starting out with Docker should be fun and relatively straightforward.</p>

CC BY-SA 3.0
2017-09-20T03:40:41.503Z
This is awesome answer...I am using windows..not sure how it fits... but it has full picture that is required to start basic.. thanks a lot
niran
CC BY-SA 3.0
2017-09-20T03:44:53.187Z
One more Q, if I follow above steps does it means that wamp is not required anymore
niran
CC BY-SA 3.0
2017-09-19T21:34:50.727Z
2017-09-19T21:57:26.337Z
2017-09-19T21:57:26.337Z
AnoE
<p>As you are already using Bitbucket, <a href="https://bitbucket.org/product/features/pipelines" rel="nofollow noreferrer">Bitbucket pipelines</a> could be useful.</p>

<blockquote>
  <p>What languages are supported?</p>
  
  <p>Node, Ruby, Python, PHP, and more. Anything you can run in a Docker
  container is supported.</p>
</blockquote>

<hr>

<blockquote>
  <p>why not jenkins?</p>
</blockquote>

<p>Jenkins could be an option as well. If Bitbucket could trigger Jenkins or Jenkins could check whether there are code changes.</p>

CC BY-SA 3.0
2017-09-18T16:20:14.367Z
what is the difference b/w pipelines and Jenkins. which one easy to use
niran
CC BY-SA 3.0
2017-09-18T14:38:20.207Z
2017-09-18T15:17:40.000Z
2017-09-18T15:17:40.000Z
030
<p>You've chosen a fairly difficult stack to support. WAMP is largely used in dev environments, and the windows builds of mysql, php, and apache typically lag their Linux counterparts by a significant amount.  You can likely reuse your code, barring any hard coded or absolute paths, on Linux. Once you move to Linux, there are lots of great deployment options, the most obvious of which is probably docker. Since your stack includes a full relational database solution, and a web server, you're up against a lot of potential complexity. This makes it near impossible to give you a good answer beyond scripting something via powershell and rolling your own if you want to keep this stack on windows.  You can keep windows and swap your stack and switch languages (probably a terrible idea, depending on how far you are into this) or you can switch operating systems and keep your code, but potentially fight with a whole world of new OS frustrations. I recommend this path, but there's no solver bullet here. </p>

<p>So you have two pretty significant hurdles: 
1. Get this app running on LAMP. 
2. learn a deployment tool for LAMP.</p>

<p>Alternatively you might be able to find a specialized WAMP host who will let you do something like FTP your code to them, which you could script.  That's not really a production-worthy plan if you ever intend to scale this application, but sometimes it's smart to act small. </p>

CC BY-SA 3.0
2017-09-21T03:12:18.920Z
2017-09-21T03:12:18.920Z
esoterydactyl
<p>I have a WAMP server which hosts a Django application by using a Windows server.</p>

<p>Currently I am deploying everything manually. Now I want apply Continuous Integration concepts to an existing application.</p>

<p>What approach should I follow and what technology should I use for this?</p>

<p>Which is better server to host Django application by CD in mind</p>

<pre><code> is it Puppet,

       Chef, 

       Jenkins etc
</code></pre>

<p>Currently I am using Git as source control.</p>

CC BY-SA 3.0
2017-09-18T14:31:39.233Z
What did you find?
030
CC BY-SA 3.0
2017-09-18T14:33:25.270Z
can you please elaborate your question bit more
niran
CC BY-SA 3.0
2017-09-18T14:33:57.683Z
What kind of CD's did you consider?
030
CC BY-SA 3.0
2017-09-18T14:35:10.390Z
I have no idea where to start. I am using git, wamp, windows server
niran
CC BY-SA 3.0
2017-09-18T14:35:38.317Z
did you check bitbucket pipelines?
030
CC BY-SA 3.0
2017-09-18T14:36:14.970Z
no, what is it for, does it supports python
niran
CC BY-SA 3.0
2017-09-18T14:36:47.493Z
Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/65770/discussion-between-niran-and-030).
niran
CC BY-SA 3.0
2017-09-18T15:59:38.190Z
I have voted to close this as primarily opinion based: there are multiple technologies for doing this and no single technology is the best or recommended way to implement this. The best one will be whatever you feel best meets your needs.
James Shewey
CC BY-SA 3.0
2017-09-18T16:21:58.383Z
@JamesShewey As there is no DevOPS architecture group,I felt this the place to ask. Tell me if you are in this kind of situation what tech stack you will use. how do you bridge gap b/w deliver and development
niran
CC BY-SA 3.0
2017-09-18T16:49:39.817Z
I don't work in a windows shop, but I use Salt Stack, which is windows compatible + jenkins (not sure if that is windows compatable or if there is an equivalent). But you could also use: Puppet, chef, Travis CI, Bamboo and more.
James Shewey
CC BY-SA 3.0
2017-09-18T18:20:24.143Z
Fwiw wamp is a convenient developer tool and not something I'd use to host an application on a production server, it is a well known target lagging in term of security fixes usually, mainly due to all products lagging for their windows version and to the needed repackaging. The configurations are more aimed at debug also and reveals too much information (but this last point is configurable).
Tensibai
CC BY-SA 3.0
2017-09-19T02:27:25.520Z
@Tensibai so which one you suggest instead of wamp
niran
CC BY-SA 3.0
2017-09-19T07:31:00.767Z
I'd use a linux distribution to take advantage of the security patches from the distribution itself.
Tensibai
CC BY-SA 3.0
2017-09-19T07:32:17.113Z
Btw, puppet and chef are configuration managers, not CI systems, they may be used in a CD chain. Jenkins is a build orchestrator, more aimed at the CI part but can be used as the orchestrator for CD process
Tensibai
<continuous-integration><continuous-delivery><windows><bitbucket><python>
What approach should I follow for adopting continuous integration?
niran
# What approach should I follow for adopting continuous integration?

(Asked by: username_0 on 2017-09-18)

I have a WAMP server which hosts a Django application by using a Windows server.
Currently I am deploying everything manually. Now I want apply Continuous Integration concepts to an existing application.
What approach should I follow and what technology should I use for this?
Which is better server to host Django application by CD in mind
 is it Puppet,

       Chef, 

       Jenkins etc

Currently I am using Git as source control.

**Tags:** continuous-integration, continuous-delivery, windows, bitbucket, python

> **Comments:**
> **username_1**: What did you find?  
> **username_0**: can you please elaborate your question bit more  
> **username_1**: What kind of CD's did you consider?  
> **username_0**: I have no idea where to start. I am using git, wamp, windows server  
> **username_1**: did you check bitbucket pipelines?  
> **username_0**: no, what is it for, does it supports python  
> **username_0**: Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/65770/discussion-between-username_0-and-username_1).  
> **username_2**: I have voted to close this as primarily opinion based: there are multiple technologies for doing this and no single technology is the best or recommended way to implement this. The best one will be whatever you feel best meets your needs.  
> **username_0**: @JamesShewey As there is no DevOPS architecture group,I felt this the place to ask. Tell me if you are in this kind of situation what tech stack you will use. how do you bridge gap b/w deliver and development  
> **username_2**: I don't work in a windows shop, but I use Salt Stack, which is windows compatible + jenkins (not sure if that is windows compatable or if there is an equivalent). But you could also use: Puppet, chef, Travis CI, Bamboo and more.  
> **username_3**: Fwiw wamp is a convenient developer tool and not something I'd use to host an application on a production server, it is a well known target lagging in term of security fixes usually, mainly due to all products lagging for their windows version and to the needed repackaging. The configurations are more aimed at debug also and reveals too much information (but this last point is configurable).  
> **username_0**: @username_3 so which one you suggest instead of wamp  
> **username_3**: I'd use a linux distribution to take advantage of the security patches from the distribution itself.  
> **username_3**: Btw, puppet and chef are configuration managers, not CI systems, they may be used in a CD chain. Jenkins is a build orchestrator, more aimed at the CI part but can be used as the orchestrator for CD process  

---

## 3 answers

### Answer by username_4 on 2017-09-19. Score: 4

I am in a similar pair of shoes as you - I am currently, slowly, getting into the DevOps topics after having many, many years of conventional development (and close connections to conventional ops) behind me.

You seem to have read a few articles, or heard a few things. That is good. Let me suggest a practical approach how to go on:

1. Take your favourite application (which you or your team wrote yourself); not too large, preferably with a limited amount of services (like Apache, DB etc.) working together with your app.
2. Install `docker`, read a bit on the Dockerfile and the whole build process, and just go ahead to create one or more Dockerfiles for that application. You know already how to deploy it manually; now make it run inside a container.
   * Make it easy on yourself. Use a `FROM`parent container that is a full-blown distribution of your choice. I like `debian:jessie`, but you can pick whichever you are familiar with.
   * At the start, do not worry about image sizes. This is just a pet project. Start your Dockerfile with the `FROM`, then as many `apt-get update; apt-get install ...` as you need to get your application running. Add stuff with `ADD` and `COPY`liberally.
3. Learn how to actually run those containers; how `EXPOSE`works, how to `--link`the app together with the DB and the Apache (in case you made a separate container for that - you can skip this obviously if your app is able to serve all stuff including static pages itself). Figure out how to mount/bind `volumes`, how to debug a container by opening a shell inside it and so on. `docker-compose` is nice if you have more than one, and pretty simple to get going with.
4. Now you probably have a working setup. That's great! You have learned the basics, and you immediately feel the great power that comes from containerizing your app. You can deploy it instantly on any server, you can give it to your developer colleagues and go up and running in zero time, and so on. Enjoy that feeling for a while.
5. Make the image smaller. There are a few obvious things you can do (google...), and a few not so obvious ones (thinking is like googling, just better... :) ). If you need help on that, post more questions here.
6. Get Jenkins (feel free to do so with docker, again, if you're adventurous) and make a job to build the image from the Dockerfile and run your test suite directly in the container you built. Jenkins can check your repository for updates automatically, you don't need to bother with `git` hooks at this moment.
7. You're done! This was the CI part. For CD, after the tests are green in Jenkins, simply tag the build and send it on to your deployment server.

This should take you, if you are an experienced developer and have done these things "dry" already, not much longer than a few days. Docker itself is a pretty simple affair, there is not much more to it. One further part that makes sense to add to the puzzle is Ansible, which makes it pretty easy to manage another machine remotely (i.e. for installing packages, deploying stuff, starting services and whatnot).

If you have Docker and Ansible down, just get your CI/CD pipeline to work. Google advanced, but necessary stuff like security and such. After that, you should be experienced enough to decide in which direction to go next (i.e., larger stuff like Openshift/Kubernetes, or just whatever AWS/Azure or whatever have to offer, etc.). There are a myriad of different options out there, and much of the choice seems to be pretty opinion-based. If you get into High Availability, swarms and such, it will also pretty soon get more non-trivial. But starting out with Docker should be fun and relatively straightforward.

> **Comments:**
> **username_0**: This is awesome answer...I am using windows..not sure how it fits... but it has full picture that is required to start basic.. thanks a lot  
> **username_0**: One more Q, if I follow above steps does it means that wamp is not required anymore  

---

### Answer by username_1 on 2017-09-18. Score: 3

As you are already using Bitbucket, [Bitbucket pipelines](https://bitbucket.org/product/features/pipelines) could be useful.

> What languages are supported?
>
> Node, Ruby, Python, PHP, and more. Anything you can run in a Docker
> container is supported.

---

> why not jenkins?

Jenkins could be an option as well. If Bitbucket could trigger Jenkins or Jenkins could check whether there are code changes.

> **Comments:**
> **username_0**: what is the difference b/w pipelines and Jenkins. which one easy to use  

---

### Answer by username_5 on 2017-09-21. Score: 2

You've chosen a fairly difficult stack to support. WAMP is largely used in dev environments, and the windows builds of mysql, php, and apache typically lag their Linux counterparts by a significant amount. You can likely reuse your code, barring any hard coded or absolute paths, on Linux. Once you move to Linux, there are lots of great deployment options, the most obvious of which is probably docker. Since your stack includes a full relational database solution, and a web server, you're up against a lot of potential complexity. This makes it near impossible to give you a good answer beyond scripting something via powershell and rolling your own if you want to keep this stack on windows. You can keep windows and swap your stack and switch languages (probably a terrible idea, depending on how far you are into this) or you can switch operating systems and keep your code, but potentially fight with a whole world of new OS frustrations. I recommend this path, but there's no solver bullet here.

So you have two pretty significant hurdles:
1. Get this app running on LAMP.
2. learn a deployment tool for LAMP.

Alternatively you might be able to find a specialized WAMP host who will let you do something like FTP your code to them, which you could script. That's not really a production-worthy plan if you ever intend to scale this application, but sometimes it's smart to act small.


---

